Bug #13299
osd create should not trigger action=add
0%
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
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 <loic@dachary.org>
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