Bug #19812
openclient: not swapping directory caps efficiently leads to very slow create chains
0%
Description
https://www.mail-archive.com/ceph-users@lists.ceph.com/msg34200.html
In short: if you have a ceph-fuse and a kernel client each create a directory, and then have them create files in the other client's directory, the kernel client finishes in a few seconds, but ceph-fuse finishes in a few minutes.
The user reported they get the same behavior with two ceph-fuse clients, and I reproduced that several months ago (though less dramatically than the reported numbers).
It looks like maybe Client isn't requesting directory caps that would make things much faster? Or maybe it's something else, but this seems pretty bad for clients which share data.
Updated by Zheng Yan almost 7 years ago
The reason of slow creation/deletion is that ceph-fuse sends a getattr request (check permission of test directory) before each create/unlink request, test directory's ifile lock is in 'lock' state. So each getattr request needs to wait until previous creation/deletion operation finishes. Set fuse_default_permissions to false can avoid this issue.
Updated by Greg Farnum almost 7 years ago
Zheng Yan wrote:
The reason of slow creation/deletion is that ceph-fuse sends a getattr request (check permission of test directory) before each create/unlink request, test directory's ifile lock is in 'lock' state. So each getattr request needs to wait until previous creation/deletion operation finishes. Set fuse_default_permissions to false can avoid this issue.
So ceph-fuse when working in its own directory is the exclusive client on the directory and the getattr doesn't have to block on the create? Or is there something more at work here? If that's all, it seems our heuristics aren't working well enough because the directory's creator is no longer doing any work in it.
Updated by Zheng Yan almost 7 years ago
The problem is that getattr requests for permission check should only get Ax, but they actually get pAsLsXsFs. getting file size needs to wait until previous creation/deletion operation finishes
Updated by Patrick Donnelly over 6 years ago
- Status changed from New to 12
- Severity changed from 3 - minor to 4 - irritation