[GH-ISSUE #2617] The performance decreases heavily for concurrent IOs. #1248

New issue

Open

opened 2026-03-04 01:52:32 +03:00 by kerem · 0 comments

kerem commented

2026-03-04 01:52:32 +03:00

Owner

Originally created by @fangqianan on GitHub (Dec 10, 2024).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2617

Additional Information

Version of s3fs being used (`s3fs --version`)

V1.95 (commit:561ce1e20600bab42133b5e51511483800d3ef76)

How to run s3fs, if applicable

All parameters are the default ones.

Details about issue

I started 10 processes, each of which writes 50 1MB files via s3fs concurrently. Then I read those files with the same concurrency. The performance decreases heavily as I raise up the concurrency. I tried to analyze the problem and here is what I found:

Thread 1: The flush/read api holds fent lock, and uploads files during holding this lock;
Thread 2: Writing/reading another file. In s3fs_write()/s3fs_read() -> AutoFdEntity::GetExistFdEntity() -> FdManager::GetExistFdEntity(), s3fs tried to find the other file's pseudo_fd by searching from all entities. Yet inside FindPseudoFd() every opened file's fent lock is required.

This means that once one file is being uploaded with its fent lock being held, there is a chance that other threads trying to read/write other files are blocked.

Actually, not only does this happen when a file is being uploaded, but also when a file is being downloaded in Read() with fent lock being held.

Given the information above, can you guys provide a solution to fix it? Or is there a reason why you guys designed the lock like this? Thanks!

Originally created by @fangqianan on GitHub (Dec 10, 2024). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2617  ### Additional Information #### Version of s3fs being used (`s3fs --version`) V1.95 (commit:561ce1e20600bab42133b5e51511483800d3ef76) #### How to run s3fs, if applicable  All parameters are the default ones. ### Details about issue I started 10 processes, each of which writes 50 1MB files via s3fs concurrently. Then I read those files with the same concurrency. The performance decreases heavily as I raise up the concurrency. I tried to analyze the problem and here is what I found: 1. Thread 1: The flush/read api holds fent lock, and uploads files during holding this lock; <img width="725" alt="image" src="https://github.com/user-attachments/assets/a07c2bb3-f299-4c4a-8991-e2a2f07dae2f"> 2. Thread 2: Writing/reading another file. In s3fs_write()/s3fs_read() -> AutoFdEntity::GetExistFdEntity() -> FdManager::GetExistFdEntity(), s3fs tried to find the other file's pseudo_fd by searching from all entities. Yet inside FindPseudoFd() every opened file's fent lock is required. <img width="668" alt="image" src="https://github.com/user-attachments/assets/7d16596c-1572-4a1b-ad75-b0e4f77eabff"> <img width="636" alt="image" src="https://github.com/user-attachments/assets/8e44278a-2b06-4e24-82a1-422943785c1d"> This means that once one file is being uploaded with its fent lock being held, there is a chance that other threads trying to read/write other files are blocked. Actually, not only does this happen when a file is being uploaded, but also when a file is being downloaded in Read() with fent lock being held. Given the information above, can you guys provide a solution to fix it? Or is there a reason why you guys designed the lock like this? Thanks!