Project

General

Profile

Bug #13299

osd create should not trigger action=add

Added by Loïc Dachary over 8 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
High
Assignee:
-
Target version:
-
% Done:

0%

Source:
other
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Crash signature (v1):
Crash signature (v2):

Description

There is no need for osd create to call udevadm trigger action=add. By running all actions associated with add for all block devices, it may also trigger some race conditions when block devices are interdependent (i.e. dmcrypt, multipath, etc.). Although all udevadm actions should be immune to such race conditions, the reality may be different.

Associated revisions

Revision aa2e0c40 (diff)
Added by Loic Dachary over 8 years ago

do not udevadm trigger, ceph-disk does it

There is no need for osd create to call udevadm trigger action=add. By
running all actions associated with add for all block devices, it may
also trigger some race conditions. For instance, the following happens
about 10% of the time, when using dmcrypt:

  • ceph-disk prepare --dmcrypt /dev/vdb
  • /dev/vdb1 starts activating via udev
  • ceph-deploy triggers action=add
  • /dev/vdb2 udev chown root /dev/vdb2
  • /dev/vdb1 activate fails because of permission denied on /dev/vdb2
  • /dev/vdb2 udev action chown ceph /dev/vdb2

http://tracker.ceph.com/issues/13299 Fixes: #13299

Signed-off-by: Loic Dachary <>

History

#1 Updated by Loïc Dachary over 8 years ago

setting the priority to high because sending a large number of udev event when it is not strictly necessary makes it more difficult to figure out what went wrong in the expected sequence of event, because it is mixed with a burst of non necessary events

#2 Updated by Loïc Dachary over 8 years ago

  • Status changed from 12 to Resolved

Also available in: Atom PDF