Bug #16164: mds: enforce a dirfrag limit on entries - CephFS - Ceph

Actions

Copy link

Bug #16164

closed

mds: enforce a dirfrag limit on entries

Added by Sage Weil almost 8 years ago. Updated over 7 years ago.

Status:

Resolved

Priority:

High

Assignee:

Patrick Donnelly

Category:

Performance/Resource Usage

Target version:

% Done:

Source:

other

Tags:

Backport:

jewel

Regression:

Severity:

3 - minor

Reviewed:

Affected Versions:

ceph-qa-suite:

Component(FS):

Labels (FS):

Pull request ID:

Crash signature (v1):

Crash signature (v2):

Description

- add a new config option to cap the number of entries in a difrag
- set the limit an order of magnitude higher than the fragment tunable that triggers creating new fragments.
- ENOSPC if we hit the limit on mknod, openc, mkdir, symlink, rename, link.

This will prevent users with fragmentation turned off from creating huge omap directories.

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by Sage Weil almost 8 years ago

Project changed from Ceph to CephFS

Actions

Copy link

Updated by Patrick Donnelly almost 8 years ago

Assignee set to Patrick Donnelly

I'm taking a look at this one.

Actions

Copy link

Updated by Patrick Donnelly almost 8 years ago

Status changed from New to In Progress

Actions

Copy link

Updated by Greg Farnum almost 8 years ago

Hmm, I was talking to m0zes (whose situation kicked off this bug) and it turns out the objects actually causing the issue are the stray directories rather than the large user directories.

He says he'd actually be okay with disallowing deletes as well, if it prevents the issue from recurring in his cluster. I wouldn't want to do that by default, but it might be pretty simple to set up with a default-off config option. How do others feel about that? I imagine it can hook in in pretty much the same ways as the rename logic will.

Actions

Copy link

Updated by Xiaoxi Chen almost 8 years ago

Greg Farnum wrote:

Hmm, I was talking to m0zes (whose situation kicked off this bug) and it turns out the objects actually causing the issue are the stray directories rather than the large user directories.

He says he'd actually be okay with disallowing deletes as well, if it prevents the issue from recurring in his cluster. I wouldn't want to do that by default, but it might be pretty simple to set up with a default-off config option. How do others feel about that? I imagine it can hook in in pretty much the same ways as the rename logic will.

Could I have more background on m0zes 's issue? This ticketed is from our previous bug report http://tracker.ceph.com/issues/16010#change-71438

Actions

Copy link

Updated by Greg Farnum almost 8 years ago

He's got more info in http://tracker.ceph.com/issues/16177.

Basically, a CephFS user created directories large enough to start causing problems with reading the omap entries fast enough for OSD recovery to work (just reading the entries out of leveldb took too long); and then deleted the entries so quickly that the stray directories got really large.

Actions

Copy link