Bug #16164
closed
mds: enforce a dirfrag limit on entries
Added by Sage Weil almost 8 years ago.
Updated over 7 years ago.
Category:
Performance/Resource Usage
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.
- Project changed from Ceph to CephFS
- Assignee set to Patrick Donnelly
I'm taking a look at this one.
- Status changed from New to In Progress
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.
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
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.
- Status changed from In Progress to 17
- Status changed from 17 to Pending Backport
- Backport set to jewel
- Copied to Backport #16560: jewel: mds: enforce a dirfrag limit on entries added
- Category set to Performance/Resource Usage
- Status changed from Pending Backport to Resolved
Also available in: Atom
PDF