mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-26 05:45:57 +03:00
[GH-ISSUE #2463] Deadlock during concurrent writes with low cache space #1215
Labels
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/s3fs-fuse#1215
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @amarjayr on GitHub (Jun 3, 2024).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2463
Additional Information
Version of s3fs being used (
s3fs --version)Details about issue
There is an unrecoverable deadlock during concurrent writes due to lock order inversion involving
fdent_lockandfd_manager_lock.In the first path,
FdEntity::Writeacquiresfdent_lockand thenfdent_data_lock. InWriteMultipartNoCacheLoadAndPost,ChangeEntityToTempPathattempts to acquirefd_manager_lock. In this case, locks are acquired in this order:fdent_lock,fdent_data_lock,fd_manager_lock.In the second path,
FdManager::GetExistFdEntity(which is called from s3fs_flush, s3fs_fsync, s3fs_read, s3fs_write) acquiresfd_manager_lock. Then, inFindPseudoFdattempts to acquirefdent_lockfor every fd entry. In this case, locks are acquired in this order:fd_manager_lock,fdent_lock.I have been able to reproduce with the following python script:
@amarjayr commented on GitHub (Jun 10, 2024):
Apologies, this is a duplicate of #2438. Closing