The FUSE mount currently does not support the new feature introduced in v1.3, which accelerates concurrent file creation and deletion in the same directory when using the SQL metadata engine

[tanchihpin0517]

What would you like to be added:
In #6285, we tested four scenarios involving concurrent file creation and deletion in the same directory, using both the Python SDK and a simple Python script (via the FUSE layer), under single- and multi-processing settings. We observed a performance drop when using multi-processing with the Python script.

Why is this needed:
Since most users interact with JuiceFS as a regular file system through the FUSE layer, we hope the new feature will also be supported when JuiceFS is mounted in this way.

[Xuyuchao-juice]

目前观测到的结果是fuse方式只要并发性能就会大幅下降，即使只开2个并发，串行的性能反而是最优的，已做了以下定位尝试

The currently observed results indicate that the fuse method experiences significant performance degradation under concurrent conditions. Even with just 2 concurrent threads, serial execution demonstrates optimal performance. The following troubleshooting attempts have been made:

1. profile 抓了两种访问方式下的access.log

   profile has captured access.log for both access patterns/methods

pysdk：

fuse：

可以发现各种请求数量基本相当，可以排除fuse缓存未生效的原因。但是lookup请求耗时差了几十倍

The analysis reveals that the request volumes are largely comparable between both methods, effectively ruling out the possibility of fuse caching being inactive. However, a striking performance discrepancy emerges in lookup requests, with response times differing by orders of magnitude (tens of times slower in the concurrent case).

2. 通过在代码打桩，定位到lookup请求增加的耗时基本上全部集中在sql操作语句中

Through code instrumentation, we've pinpointed that the additional latency in lookup requests is almost entirely concentrated within SQL operations.

3. vmstat 1 查看两种访问方式下的系统指标:
   vmstat 1 analysis reveals the following system metrics comparison between both access patterns:​​

pysdk：

fuse：

4. 还尝试在另一台机器上部署数据库实例，以及尝试测试1.2版本，没有其他收获

Additional troubleshooting attempts were made, including: Deploying the database instance on a separate machine and Testing version 1.2 of the system/component.However, these measures yielded no significant findings or performance improvements.

[tanchihpin0517]

@Xuyuchao-juice Thanks for the thorough testing and insights. Based on all the information we’ve gathered, it seems the issue may not be related to whether the new feature is applied, but rather could point to a potential bug in the JuiceFS FUSE layer, would you agree?

[Xuyuchao-juice]

Perhaps. The only difference between the two appears to be process-level concurrency versus goroutine-level concurrency. I'm still unclear why this distinction would lead to the current results—further analysis is needed.