Enable us to obtain the erasure-code-profile for a given erasure-pool.
Signed-off-by: Ma Jianpeng <jianpeng.ma@intel.com>
Signed-off-by: Sage Weil <sage@inktank.com>
Fixes: #8846
Backport: firefly, dumpling
This was broken at ea68b93723. We ended
up calling wait_pending_front() when pending list was empty.
This commit also moves the need_to_wait check to a different place,
where we actually throttle (and not just drain completed IOs).
Reported-by: Sylvain Munaut <s.munaut@whatever-company.com>
Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
(cherry picked from commit f9f2417d7d)
Fixes: #8846
Backport: firefly, dumpling
This was broken at ea68b93723. We ended
up calling wait_pending_front() when pending list was empty.
This commit also moves the need_to_wait check to a different place,
where we actually throttle (and not just drain completed IOs).
Reported-by: Sylvain Munaut <s.munaut@whatever-company.com>
Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
We want to make sure the daemon runs in its own systemd environment. Check
for systemd as pid 1 and, when present, use systemd-run -r <cmd> to do
this.
Probably fixes#7627
Signed-off-by: Sage Weil <sage@redhat.com>
Reviewed-by: Dan Mick <dan.mick@inktank.com>
Tested-by: Dan Mick <dan.mick@inktank.com>
This clarifies how to deal with layouts in CephFS
using vxattrs. We can point people here if they
ask what they should use instead of the deprecated
`cephfs set_layout`.
Signed-off-by: John Spray <john.spray@redhat.com>
`cephfs set_layout` was broken and is now deprecated
in favour of using xattrs for layout. Retire the
kclient-specific test.
Fixes: #8773
Signed-off-by: John Spray <john.spray@redhat.com>
These commands are intended to help admins deal
with MDSs during recovery, to identify troublesome
clients which may need intervention (such as eviction).
Signed-off-by: John Spray <john.spray@redhat.com>
There are cases when automatic (un-)mounting of file system on RBD is not
enough. Some services may need to be started when RBD device becomes
available (mapped) as well as it may be desirable to stop services in order
to release file system before unmapping RBD device.
File system(s) on RBD is not the only use case scenario. RBD devices may be
used as block devices in which case `/etc/fstab` is not sufficient to
perform action upon mapping RBD device. A handler script (hook) can be
useful to properly release RBD device before unmapping, etc.
Pre-unmap hooks can be important for clean shut down and for re-exporting
RBD device(s) as (iSCSI,AoE,DRBD) etc.
This commit introduces support for per-device hooks to perform per-device
post-map/pre-unmap actions. If hook named like "poolname/imagename" (same
as in `/etc/ceph/rbdmap` file) is found in
/etc/ceph/rbd.d/poolname/imagename
it is executed as
/etc/ceph/rbd.d/poolname/imagename map poolname/imagename
following after attempt to mount file system (if relevant `fstab` entry
exist) following mapping of corresponding RBD device.
Before un-mounting file system and un-mapping RBD device hook is called as
follows:
/etc/ceph/rbd.d/poolname/imagename unmap poolname/imagename
Second argument is intentional to allow multiple RBD devices to share the
same hook (symlinked under different names).
Sample hook to use RBD device as "mdadm" hot spare may look like this:
~~~~
DEV="$2"
case "$1" in
"map")
mdadm /dev/md2 --add --write-mostly "${DEV}"
;;
"unmap")
mdadm /dev/md2 --fail "${DEV}"
sleep 2
mdadm /dev/md2 --remove "${DEV}"
;;
esac
~~~~
Signed-off-by: Dmitry Smirnov <onlyjob@member.fsf.org>
The addition of the value is completely backward compatible, but if the
mon feature bits don't match it can cause monitor scrub noice (due to the
parallel OSDMap encoding). Avoid that by only adding the new field if the
feature (which was added 2 patches after the encoding, see
3152faf79f and
45e79a17a9.
Fixes: #8815
Backport: firefly
Signed-off-by: Sage Weil <sage@redhat.com>
This is left over from db3fd1152a
when we made the HitSet stuff incompat, but that behavior was reverted by
dc3ce58add, leaving this cruft behind.
Signed-off-by: Sage Weil <sage@redhat.com>