* Removing tiers from a base pool in use by CephFS is forbidden.
* Using CephFS pools as tiers is forbidden.
Signed-off-by: John Spray <john.spray@redhat.com>
Fixes two things:
* EC pools are now permissible if they have a cache overlay
* Pools are not permissible if they are a cache tier.
Fixes: #9435
Signed-off-by: John Spray <john.spray@redhat.com>
This is mostly relevant in testing clusters, but it ensures that an OSD
disconnecting from the monitor at the wrong time will still see any recent
map updates and prevent accidental loss of map injection into the OSD cluster.
Fixes: #9219
Signed-off-by: Greg Farnum <greg@inktank.com>
We did this forever ago with mkcephfs, but ceph-disk didn't. Note that for
modern XFS this option is obsolete, but for older kernels it was not the
default.
Backport: firefly
Signed-off-by: Sage Weil <sage@redhat.com>
This is to avoid hitting an O(caps) loop in the worst
cast scenario. This mechanism is a little crude but
should be superceded at some point by admin socket
functionality to inspect session caps so that we
don't need to spit out this level of detail in logs.
Signed-off-by: John Spray <john.spray@redhat.com>
...to avoid doing an O(caps) scan to find out
which clients are responsible for any late-revoking
caps during health checks.
Signed-off-by: John Spray <john.spray@redhat.com>
Follow up on Yan Zheng's "mds: warn clients which
aren't revoking cap" to include a health metric
for this condition as well as the clog messages.
Signed-off-by: John Spray <john.spray@redhat.com>
To be used later for generating health metrics
for clients which are failing to promptly service
CEPH_SESSION_RECALL_STATE messages.
Signed-off-by: John Spray <john.spray@redhat.com>
Previously client would fail to release caps for files
in the root directory in response to CEPH_SESSION_RECALL_STATE
messages.
Signed-off-by: John Spray <john.spray@redhat.com>
Used for simulating a buggy client that trips
the error detection in #9282 (warn clients
which aren't revoking caps)
Signed-off-by: John Spray <john.spray@redhat.com>
trim_dentry can potentially free an inode, so get/put
it around the block where we use the inode's dn_set.
Signed-off-by: John Spray <john.spray@redhat.com>
Two fixes:
* Client would unlink everything it could, instead of just
meeting its goal, because caps.size() doesn't change until
dentries are cleaned up later. Take account of the trimmed
count in the while() condition to fix that.
* Don't count the root ino as trimmed, as although it has no
dentries (of course), we will never give up the cap.
With this change, the client will now precisely achieve the number
of caps requested in CEPH_SESSION_RECALL_STATE messages.
Signed-off-by: John Spray <john.spray@redhat.com>
In a75af4c2, procedure was added to invalidate root's dentries
if the trimming failed to free enough caps. This would sometimes
crash because root->dir wasn't necessarily open.
Fix by only doing it if root dir is open, though I suspect this
may not be the end of it...
Signed-off-by: John Spray <john.spray@redhat.com>
osd_backfill_scan_min and osd_backfill_scan_max set the number of
items grabbed during a single backfill scan, not an interval in
seconds. Correct the doc.
Signed-off-by: Dan van der Ster <daniel.vanderster@cern.ch>
When using RHEL7 the radosgw daemon needs to start under systemd.
Check for systemd running on PID 1. If it is then start
the daemon using: systemd-run -r <cmd>. pidof returns null
as it is executed too quickly, adding one second of sleep and
script reports startup correctly.
Signed-off-by: JuanJose 'JJ' Galvez <jgalvez@redhat.com>
Describes the CLI for adding and removing buckets, in addition to the
'moving' instructions which were already present.
Signed-off-by: Stephen Jahl <stephenjahl@gmail.com>
... to avoid leaving log events that reference log
segments by offsets which no longer exist.
Signed-off-by: John Spray <john.spray@redhat.com>
(cherry picked from commit 386f2d7c82)
Reviewed-by: Greg Farnum <greg@inktank.com>
Test that the segv injection works.
Test that a segv while logging something doesn't hang when the signal
handlers are installed. Note that this fails/hangs without the previous
fix.
Signed-off-by: Sage Weil <sage@redhat.com>
This might have been the culprit for #9307. Before we were calculating
the hash after the call to processor->handle_data(), however, that
method might have spliced the bufferlist, so we can't be sure that the
pointer that we were holding originally is still invalid. Instead, push
the hash calculation down. Added a new explicit complete_hash() call to
the processor, since when we're at complete() it's too late (we need to
have the hash at that point already).
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
