Kefu Chai [Fri, 7 Aug 2020 08:49:58 +0000 (16:49 +0800)]
common/ConfUtils: expose parse_buffer()
so it can be used by crimson for reading settings from a conf file.
crimson reads file with async read. since we already have a specialized
ConfigProxy for crimson, it'd be simpler to expose the shared facility
from ConfUtils instead of specializing it in ConfUtils.
Kefu Chai [Fri, 7 Aug 2020 08:28:30 +0000 (16:28 +0800)]
crimson/osd: use "ceph" for default cluster_name
for couple reasons:
* to avoid the pain to guess / update the cluster name when loading
conf file. in the past, we use "ceph" as a fallback for the cluster
name, which is in turn used as a meta name when expanding setting
values containing "$cluster". so to ensure those settings continue
working, we have to at least set cluster_name a safe value, and
"ceph" is what we've been using.
* in
http://lists.ceph.com/pipermail/ceph-users-ceph.com/2017-June/018519.html,
we decided to drop the cluster_name support in deploy tools, and to
keep this feature in code. so in the long run, we can assume
new clusters will be all named "ceph".
* it's difficult to properly implement the feature to use "ceph",
if no --conf option is specified, as, in Ceph, even the path pointing
to conf file is allowed to contain "$cluster". so, to get it
right, we need to update cluster name stored in options before
reading the option files, this forces us to populate the setting
twice when reading the settings from a conf file. or we could
specialize the process, but i don't think it worthy of the
efforts.
so i think we can just use "ceph" for the cluster name in crimson.
* refs/pull/36501/head:
qa: add tests for mds_min_caps_working_set
mds: add working set minimum for caps
qa: use config_set/config_get
qa: do not append file names to dirname
qa: add exception for test timeouts
A client may hold many inodes pinned in its cache for open files. That
client may be unable to release those caps to respond to cache pressure
from the MDS (or quiescent client cap recall). We should not complain if
that number of capabilities is reasonable (< 10k by default).
Fixes: https://tracker.ceph.com/issues/46830 Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
Otherwise the files generated are not actually under the sub-directory!
This is correcting a confusing aspect of the test infrastructure but
doesn't actually require any changes to the tests.
Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
librbd/cache: Fix scoping issue with lambda capture renaming
Clang complains:
/home/jenkins/workspace/ceph-master-compile/src/librbd/cache/ParentCacheObjectDispatch.cc:97:66: error: 'object_off' in capture list does not name a variable
([this, read_data, dispatch_result, on_dispatched, object_no, object_off,
^
/home/jenkins/workspace/ceph-master-compile/src/librbd/cache/ParentCacheObjectDispatch.cc:98:6: error: 'object_len' in capture list does not name a variable
object_len, snap_id, &parent_trace](ObjectCacheRequest* ack) {
^
/home/jenkins/workspace/ceph-master-compile/src/librbd/cache/ParentCacheObjectDispatch.cc:99:41: error: reference to local binding 'object_off' declared in enclosing function 'librbd::cache::ParentCacheObjectDispatch::read'
handle_read_cache(ack, object_no, object_off, object_len, snap_id,
^
/home/jenkins/workspace/ceph-master-compile/src/librbd/cache/ParentCacheObjectDispatch.cc:81:9: note: 'object_off' declared here
auto [object_off, object_len] = extents.front();
^
/home/jenkins/workspace/ceph-master-compile/src/librbd/cache/ParentCacheObjectDispatch.cc:99:53: error: reference to local binding 'object_len' declared in enclosing function 'librbd::cache::ParentCacheObjectDispatch::read'
handle_read_cache(ack, object_no, object_off, object_len, snap_id,
^
/home/jenkins/workspace/ceph-master-compile/src/librbd/cache/ParentCacheObjectDispatch.cc:81:21: note: 'object_len' declared here
auto [object_off, object_len] = extents.front();
^
/home/jenkins/workspace/ceph-master-compile/src/librbd/cache/ParentCacheObjectDispatch.cc:99:41: error: reference to local binding 'object_off' declared in enclosing function 'librbd::cache::ParentCacheObjectDispatch<librbd::ImageCtx>::read'
handle_read_cache(ack, object_no, object_off, object_len, snap_id,
^
/home/jenkins/workspace/ceph-master-compile/src/librbd/cache/ParentCacheObjectDispatch.cc:242:31: note: in instantiation of member function 'librbd::cache::ParentCacheObjectDispatch<librbd::ImageCtx>::read' requested here
template class librbd::cache::ParentCacheObjectDispatch<librbd::ImageCtx>;
^
/home/jenkins/workspace/ceph-master-compile/src/librbd/cache/ParentCacheObjectDispatch.cc:81:9: note: 'object_off' declared here
auto [object_off, object_len] = extents.front();
^
/home/jenkins/workspace/ceph-master-compile/src/librbd/cache/ParentCacheObjectDispatch.cc:99:53: error: reference to local binding 'object_len' declared in enclosing function 'librbd::cache::ParentCacheObjectDispatch<librbd::ImageCtx>::read'
handle_read_cache(ack, object_no, object_off, object_len, snap_id,
^
/home/jenkins/workspace/ceph-master-compile/src/librbd/cache/ParentCacheObjectDispatch.cc:81:21: note: 'object_len' declared here
auto [object_off, object_len] = extents.front();
^
6 errors generated.
fixes: https://github.com/ceph/ceph/pull/36145 Signed-off-by: Willem Jan Withagen <wjw@digiware.nl>
crimson/osd: spawn osd_op_params in do_write_op(). Fix overriding.
This commit deduplicates the `OpsExexuter::do_osd_op()` by moving
`std::optional`-typed `osd_op_params` instantiation to `do_write_op()`.
It also fixes an issue where `clean_regions` of `osd_op_params` were
reset on every write, writefull or truncate.
Tim Serong [Wed, 5 Aug 2020 06:34:20 +0000 (16:34 +1000)]
cephadm: don't add `ceph-volume lvm activate` for adopted simple OSDs
This changes the logic in deploy_daemon_units() to add either `chown` calls
for simple (ceph-disk style) OSDs, or to add `ceph-volume lvm activate` calls
for LVM OSDs, rather than always adding both. When I was working on
https://github.com/ceph/ceph/pull/34703, I'd originally added an "osd_simple"
flag to figure out what type of OSD was being adopted/deployed, but passing
that around was kinda ugly, so was removed from that PR. This time around
I'm checking if /etc/ceph/osd/$OSD_ID-$OSD_FSID.json.adopted-by-cephadm
exists, which seems pretty safe IMO. My only concern with this method is:
what happens if someone adopts a simple OSD, then later wants to migrate it
to LVM. Presumably that's a destroy and recreate, keeping the same OSD ID?
If that's true, then the JSON file probably still exists, so the subsequent
create will do the wrong thing, i.e. will add `chown` calls, not `ceph-volume
lvm activate` calls. Any/all feedback appreciated...
Fixes: https://tracker.ceph.com/issues/46833 Signed-off-by: Tim Serong <tserong@suse.com>
Kefu Chai [Tue, 4 Aug 2020 07:20:46 +0000 (15:20 +0800)]
crimson/admin: read non-string settings as well
before this change, we were using
local_conf().get_val<std::string>(var);
for reading a setting when serving a "config get" command even if the
setting being queried is a non-string. so without this change, a failure
is returned complaining "unrecognized option..."
in this change:
* use get_val(string,string*) for querying the string representation
of the queried setting
* drop the check for existence of "var" parameter, validate_cmd()
always take care of this.
Kefu Chai [Sat, 1 Aug 2020 15:38:15 +0000 (23:38 +0800)]
common/HeartbeatMap: use relaxed order
use memory_order_relaxed instead of memory_order_seq_cst, as the
ordering of storing of `timeout` and `suicide_timeout` does not matter,
and we don't need to synchorinize the cache for the consistent memory
view of local core. what we need is but the atomic read/write operation
of these individual variables.
projects / ceph-ci.git / log