Samuel Just [Wed, 23 Nov 2016 23:41:13 +0000 (15:41 -0800)]
ReplicatedBackend: take read locks for clone sources during recovery
Otherwise, we run the risk of a clone source which hasn't actually
come into existence yet being used if we grab a clone which *just*
got added the the ssc, but has not yet actually had time to be
created (can't rely on message ordering here since recovery messages
don't necessarily order with client IO!).
Fixes: http://tracker.ceph.com/issues/17831 Signed-off-by: Samuel Just <sjust@redhat.com>
Samuel Just [Tue, 3 Jan 2017 18:50:22 +0000 (10:50 -0800)]
PrimaryLogPG: don't update digests for objects with mismatched names
I've only seen this on one cluster, but let's not issue repops during
scrub on objects where the object_info_t::soid value is not correct.
The cluster in question has been through many different non-release
kernels and osd versions, so the objects presumably came about due to an
old xfs or filestore bug. They recently became fatal since we made
filestore crash on ENOENT for setattrs. In the past, the cluster just
silently tolerated them.
http://tracker.ceph.com/issues/18409 is a larger feature to detect these
better and repair them automatically.
Related: http://tracker.ceph.com/issues/18409 Signed-off-by: Samuel Just <sjust@redhat.com>
Sage Weil [Thu, 22 Dec 2016 18:05:22 +0000 (13:05 -0500)]
qa/tasks/workunit: clear clone dir before retrying checkout
If we checkout ceph-ci.git, and don't find a branch,
we'll try again from ceph.git. But the checkout will
already exist and the clone will fail, so we'll still
fail to find the branch.
The same can happen if a previous workunit task already
checked out the repo.
Fix by removing the repo before checkout (the first and
second times). Note that this may break if there are
multiple workunit tasks running in parallel on the same
role. That is already racy, so if it's happening, we'll
want to switch to using a truly unique clonedir for each
instantiation.
Fixes: http://tracker.ceph.com/issues/18336 Signed-off-by: Sage Weil <sage@redhat.com>
It so happens that it's not safe to assume the monmap will be in an
empty state upon decoding.
Turns out the MonClient will reuse the MonMap instance when decoding
the just received map from the monitors. Should the monitors be on an
older version that do not support 'mon_info', this field will not be
decoded (after all, there's no field to decode from); but by this time,
the MonClient would already have a built monmap, which could have
populated 'mon_info' with temporary mon names from 'mon initial
members'.
Given the existing entries in 'mon_info', and the conflicting entries in
'mon_addr', we would end up asserting in 'sanitize_mons()'. This becomes
a non-issue if 'mon_info' is empty, as was unfortunately presumed.
Fixes: http://tracker.ceph.com/issues/18265 Signed-off-by: Joao Eduardo Luis <joao@suse.de>
Samuel Just [Tue, 20 Dec 2016 17:47:41 +0000 (09:47 -0800)]
osd/: treat PINGs as RWORDERED
89fd030bf9436dc4e37cc3a0f935ec077455d9d5 switched them to show up
as reads to avoid logging them, but we still pipeline them with
reconnects. Thus, also force them to be rwordered.
Fixes: http://tracker.ceph.com/issues/18310 Signed-off-by: Samuel Just <sjust@redhat.com>
Sage Weil [Mon, 19 Dec 2016 22:04:26 +0000 (17:04 -0500)]
os/bluestore: preserve source collection cache during split
OSD split transactions look something like
mkcoll new
split old
...
omap_rmkey_range old
omap_setkeys old
omap_setkeys new
The last part splits the log into two pieces. The
problem is that the rmkey_range needs to wait on old
omap transactions to flush, and those are linked to the
old onode, and split clears the cache. The result is
that we don't wait, rmkeyrange leaves some recent pg log
keys behind, and on OSD restart we get an error because
the object doesn't belong to the (old) collection.
Fix this by preserving objects in the old collection and
only clear out objects that are moving to the newly
split collections. This will include the pgmeta object
that we care about.
(Note that we are one step closer to preserving the
cache contents across the split, but not quite there
yet: at this point we don't have all of the destination
collections. A change in the ObjectStore interface is
probably needed to make that not be extremely awkward.)
Sage Weil [Mon, 19 Dec 2016 15:03:44 +0000 (10:03 -0500)]
os/bluestore: include modified objects in flush list even if onode unchanged
We use the onode flush list so that we can ->flush() as
a barrier before doing any read/modify/write. For
example, omap_rmkeyrange will flush before reading to
see what keys to erase in order to ensure that any
previous inserts are applied to the db and we see them
and remove them.
However, some omap operations don't update the onode
itself, which means write_onode() doesn't get called and
we aren't put on this list.
Add a note_modified_object() helper that can be called
instead of write_onode() for those cases. That way we
get on the list and flush() works as expected.
We could have resolved this by just putting ourselves on
the dirty onode list, but in practice every OSD op is
writing omap keys to the pgmeta object and there is no
need to touch the onode key in this case, so doing so
would be a big regression.
Avner BenHanoch [Tue, 6 Dec 2016 09:38:36 +0000 (09:38 +0000)]
msg/async/rdma: fix bad message that went to the user
1. the printed value of "bad length" was incorrect, because 'r' was changed before the log line.
2. log appeared to user as error even though everything was calm; hence, reducing its severity
Jeff Layton [Fri, 16 Dec 2016 15:19:18 +0000 (10:19 -0500)]
client: set metadata["root"] from mount method when it's called with a pathname
Currently, we only set the root properly config file or the
--client_metadata command line option. If a userland client program
tries to call ceph_mount with a pathname, it's not being properly
set.
Since we already hold the mutex, we can just update it directly.
Jason Dillaman [Wed, 14 Dec 2016 18:13:15 +0000 (13:13 -0500)]
librbd: keep rbd_default_features setting as bitmask
Support both human readable, comma delimited list of feature
names and also integer bitmask value. Attempting to read the
setting will always result in the feature bitmask integer
value.
This is required to avoid breaking backwards compatibility with
librbd clients that are dependent on the older behavior (e.g.
OpenStack).
Fixes: http://tracker.ceph.com/issues/18247 Signed-off-by: Jason Dillaman <dillaman@redhat.com>