Project

General

Profile

Actions
Copy link

Backport #36640

closed

luminous: Unable to recover from ENOSPC in BlueFS

Added by Patrick Donnelly over 5 years ago. Updated about 3 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Target version:
-
Release:
luminous
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Related issues 1 (0 open — 1 closed)

Copied from bluestore - Bug #36268: Unable to recover from ENOSPC in BlueFSResolvedIgor Fedotov

Actions
Actions
Copy link
 #1

Updated by Patrick Donnelly over 5 years ago

  • Copied from Bug #36268: Unable to recover from ENOSPC in BlueFS added
Actions
Copy link
 #2

Updated by Nathan Cutler over 5 years ago

  • Status changed from New to Need More Info
  • Assignee set to Igor Fedotov

Igor writes in the parent issue: "In fact previously mentioned PR is just a workaround to be able to manually fix the issue.
Working on the actual solution to fix BlueFS allocation strategy."

Actions
Copy link
 #3

Updated by Nathan Cutler about 5 years ago

  • Status changed from Need More Info to New
Actions
Copy link
 #4

Updated by Prasad Krishnan over 4 years ago

It appeared to me that increasing "bluefs_min_log_runway" config option to a really high value is one way to prevent this problem from occuring on OSDs where the fix (https://github.com/ceph/ceph/pull/25132/commits) isn't available, since the write operations would get prevented early (in case of low-space) and compaction can happen without trampling on the last available free-space.

Can someone comment on whether this looks like a good workaround to prevent the condition?

Actions
Copy link
 #5

Updated by Nathan Cutler about 3 years ago

  • Status changed from New to Rejected
  • Assignee deleted (Igor Fedotov)

luminous EOL

Actions
Copy link

Also available in: Atom PDF