Project

General

Profile

Bug #19812

client: not swapping directory caps efficiently leads to very slow create chains

Added by Greg Farnum over 2 years ago. Updated about 2 years ago.

Status:
Verified
Priority:
Normal
Assignee:
-
Category:
Performance/Resource Usage
Target version:
-
Start date:
04/28/2017
Due date:
% Done:

0%

Source:
Community (user)
Tags:
Backport:
Regression:
No
Severity:
4 - irritation
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
ceph-fuse
Labels (FS):
Pull request ID:

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.

History

#1 Updated by Zheng Yan over 2 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.

#2 Updated by Greg Farnum about 2 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.

#3 Updated by Zheng Yan about 2 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

#4 Updated by Patrick Donnelly about 2 years ago

  • Status changed from New to Verified
  • Severity changed from 3 - minor to 4 - irritation

Also available in: Atom PDF