If an image is being bootstrapped, it implies that the rbd-mirror
daemon currently has the image open. The removal API will prevent the
removal of any image that is opened by another client.
Works-around: http://tracker.ceph.com/issues/16555
Signed-off-by: Mykola Golub <mgolub@mirantis.com>
this fixes failures like,
/home/jenkins-build/build/workspace/ceph-pull-requests/qa/workunits/cephtool/test.sh:
line 32: ceph osd blacklist ls | grep 192.168.0.1: command not found
where the failure is not the "failure" we are expecting.
in our tests, following command
expect_false "ceph osd blacklist ls | grep 192.168.0.1"
is designed to to verify that "ceph osd blacklist ls | grep 192.168.0.1"
fails with non-zero return code. but expect_false() evaluates the command
line using plain "$@", which will send the arguments direct to the shell,
and $0 is "ceph auth get client.xx | grep caps | grep mon", which does
not exist and is not built-in command. so we need to check the grep
command instead.
for multiple piped command line, use
expect_false sh <<< "echo foo | grep bar | grep baz"
Signed-off-by: Kefu Chai <kchai@redhat.com>
Under certain circumstances ceph-authtool can create invalid key entries in
the specified keyring and behave less than intuitively. What's worse these
keys can currently cause ceph daemons to crash. This patch attempts to tighten
the behaviour and eliminate the possibility an invalid key can be created.
Fixes: http://tracker.ceph.com/issues/2904
Signed-off-by: Brad Hubbard <bhubbard@redhat.com>
1. pre-calculate r, so we don't have to do the division each loop, which
is expensive.
2. make sure the extent to be allocated is within the block device size.
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
Macros for various sorts of alignment and rounding.
So we can get rid of the annoying division and mod operation and simplify
the blob/space access logic.
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
Wrap partprobe with flock to stop udev from issuing BLKRRPART because
this is racy and frequently fails with a message like:
Error: Error informing the kernel about modifications to partition
/dev/vdc1 -- Device or resource busy. This means Linux won't know about
any changes you made to /dev/vdc1 until you reboot -- so you shouldn't
mount it or use it in any way before rebooting.
Opening a device (/dev/vdc for instance) in write mode indirectly
triggers a BLKRRPART ioctl from udev (starting version 214 and up)
when the device is closed (see below for the udev release note).
However, if udev fails to acquire an exclusive lock (with
flock(fd, LOCK_EX|LOCK_NB); ) the BLKRRPART ioctl is not issued.
045e00cf16/src/udev/udevd.c (L1042)
Acquiring an exclusive lock before running the process that opens the
device in write mode is therefore an effective way to control this
behavior.
git clone git://anonscm.debian.org/pkg-systemd/systemd.git
systemd/NEWS:
CHANGES WITH 214:
* As an experimental feature, udev now tries to lock the
disk device node (flock(LOCK_SH|LOCK_NB)) while it
executes events for the disk or any of its partitions.
Applications like partitioning programs can lock the
disk device node (flock(LOCK_EX)) and claim temporary
device ownership that way; udev will entirely skip all event
handling for this disk and its partitions. If the disk
was opened for writing, the close will trigger a partition
table rescan in udev's "watch" facility, and if needed
synthesize "change" events for the disk and all its partitions.
This is now unconditionally enabled, and if it turns out to
cause major problems, we might turn it on only for specific
devices, or might need to disable it entirely. Device Mapper
devices are excluded from this logic.
Fixes: http://tracker.ceph.com/issues/15176
Signed-off-by: Marius Vollmer <marius.vollmer@redhat com>
Signed-off-by: Loic Dachary <loic@dachary.org>
