Project

General

Profile

Actions

Bug #11907

closed

crushmap validation must not block the monitor

Added by Loïc Dachary almost 9 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
High
Assignee:
-
Category:
Performance/Resource Usage
Target version:
-
% Done:

0%

Source:
other
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(RADOS):
Monitor
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

Not only does it fail if the machine is slow, it will also systematically fail if the crushmap contains a ruleset that takes more than 5 sec to test no matter what: it can be reproduced by creating an erasure coded ruleset with a max_size > 20.

    check_response: 96: '[' '' -a '!=' ']'
    check_response: 101: grep --quiet -- 'Error EINVAL: Failed to parse crushmap: /tmp/cephtool12221/crushtool: timed out (5 sec)' /tmp/cephtool12221/test_invalid.12221
    test_mon_crushmap_validation: 1581: ceph tell 'mon.*' injectargs --crushtool crushtool
    *** DEVELOPER MODE: setting PATH, PYTHONPATH and LD_LIBRARY_PATH ***
    make[2]: *** [check-recursive] Terminated


Related issues 1 (0 open1 closed)

Related to Ceph - Bug #14136: "Error EINVAL: crushtool check failed with -22" in upgrade:infernalis-infernalis-distro-basic-openstackWon't Fix12/20/2015

Actions
Actions #1

Updated by Loïc Dachary about 8 years ago

  • Related to Bug #14136: "Error EINVAL: crushtool check failed with -22" in upgrade:infernalis-infernalis-distro-basic-openstack added
Actions #2

Updated by Greg Farnum almost 7 years ago

  • Project changed from Ceph to RADOS
  • Category set to Performance/Resource Usage
  • Component(RADOS) Monitor added

Don't we internally time out crush map testing now? Does it behave sensibly if things take too long?

Actions #3

Updated by Sage Weil over 6 years ago

  • Status changed from 12 to Closed

there is a timeout

Actions

Also available in: Atom PDF