otherwise when we are kicking the PG waiting in OSD's awaiting_throttle
queue, the queue is still holding a strong reference of it. then we will
have warnings like "pgid 0.7 has ref count of 2" when shutting down OSD,
because pgmap is also holding a reference of it.
we could clear the "awaiting_throttle" directly in OSD::shutdown(), but
clear_queued_recovery() is more consistent this way, because it is PG
which registered itself to the queue in OSD, it'd be better if PG can
remove itself from the OSD when it is shutting down itself.
Fixes: http://tracker.ceph.com/issues/20432
Signed-off-by: Kefu Chai <kchai@redhat.com>
This isn't strictly accurate since we're really deprecating, but the
message is appropriately scary and reflects the risk of data loss.
Signed-off-by: Sage Weil <sage@redhat.com>
during cache tier dirty data flushing, cache tier osd memroy consumption
will get increasing due to the accumulative pg log which will not be trimmed
Fixes: http://tracker.ceph.com/issues/20464
Signed-off-by: Peng Xie <peng.hse@xtaotech.com>
All options to en/disable inclusion of libraries or other software
are of the format WITH_ so that the Cmake commaind like ahs all
WITH_* options. The WITH_=ON option will result in a HAVE_ setting
in CMAKE so that tests can use that variable.
Last "abusers" to actually follow this format.
- HAVE_BABELTRACE
- HAVE_ZFSLIB is fixed in #15907
Signed-off-by: Willem Jan Withagen <wjw@digiware.nl>
We submit aios while holding deferred_lock, and we take deferred_lock in
the aio completion handler (of which there is only 1). That means that
if the aio queue fills up, the submitter will block with the lock while
the finisher won't be able to take the lock, progress, and drain completed
aios, leading to a deadlock.
Fix this by submiting aios *without* deferred_lock held. Instead, demote
to a deferred_submit_lock. Further, in the finisher, submit aios
via a finisher (this only happens when in deferred_aggressive mode which
is rare and not performance-sensitive).
Signed-off-by: Sage Weil <sage@redhat.com>
Use path of script to look for 'am I in a build tree' rather than
getcwd(), so that 'build tree' versions can be run from anywhere
Fixes: http://tracker.ceph.com/issues/20472
Signed-off-by: Dan Mick <dan.mick@redhat.com>
os/filestore/FileStore.cc: remove a redundant judgement when get max latency
Reviewed-by: xie xingguo <xie.xingguo@zte.com.cn>
Reviewed-by: Pan Liu <liupan1111@gmail.com>
crush_choose_arg::ids array is encoded on the wire. int is not fixed
size -- use __s32 instead (crush_bucket::id is __s32).
This was introduced in commit dbe36e08be ("crush: compile/decompile
crush_choose_arg_map") under SERVER_LUMINOUS bit.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
choose_args.size() returns size_t, which is not fixed size. Given that
choose_args code just open-codes our std::map encoder, do what we do for
std::map.
This was introduced in commit dbe36e08be ("crush: compile/decompile
crush_choose_arg_map") under SERVER_LUMINOUS bit.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
The PartOf= and WantedBy= directives in the various systemd
unit files and targets create the following logical hierarchy:
- ceph.target
- ceph-fuse.target
- ceph-fuse@.service
- ceph-mds.target
- ceph-mds@.service
- ceph-mgr.target
- ceph-mgr@.service
- ceph-mon.target
- ceph-mon@.service
- ceph-osd.target
- ceph-osd@.service
- ceph-radosgw.target
- ceph-radosgw@.service
- ceph-rbd-mirror.target
- ceph-rbd-mirror@.service
Additionally, the ceph-{fuse,mds,mon,osd,radosgw,rbd-mirror}
targets have WantedBy=multi-user.target. This gives the
following behaviour:
- `systemctl {start,stop,restart}` of any target will restart
all dependent services (e.g.: `systemctl restart ceph.target`
will restart all services; `systemctl restart ceph-mon.target`
will restart all the mons, and so forth).
- `systemctl {enable,disable}` for the second level targets
(ceph-mon.target etc.) will cause depenent services to come
up on boot, or not (of course the individual services can
be enabled or disabled as well - for a service to start
on boot, both the service and its target must be enabled;
disabling either will cause the service to be disabled).
- `systemctl {enable,disable} ceph.target` has no effect on
whether or not services come up at boot; if the second level
targets and services are enabled, they'll start regardless of
whether ceph.target is enabled. This is due to the second
level targets all having WantedBy=multi-user.target.
- The OSDs will always start regardless of ceph-osd.target
(unless they are explicitly masked), thanks to udev magic.
So far, so good. Except, several users have encountered
services not starting with the following error:
Failed to start ceph-osd@5.service: Transaction order is
cyclic. See system logs for details.
I've not been able to reproduce this myself in such a way as to
cause OSDs to fail to start, but I *have* managed to get systemd
into that same confused state, as follows:
- Disable ceph.target, ceph-mon.target, ceph-osd.target,
ceph-mon@$(hostname).service and all ceph-osd instances.
- Re-enable all of the above.
At this point, everything is fine, but if I then subseqently
disable ceph.target, *then* try `systemctl restart ceph.target`,
I get "Failed to restart ceph.target: Transaction order is cyclic.
See system logs for details."
Explicitly adding Before=ceph.target to each second level target
prevents systemd from becoming confused in this situation.
Signed-off-by: Tim Serong <tserong@suse.com>
