mds: reply -EOPNOTSUPP for unknown lock type

Signed-off-by: Yan, Zheng <zyan@redhat.com>
(cherry picked from commit 675392335c53ff7879031fb9184e4f35bcc90fe2)
Merge pull request #2740 from ceph/giant-unknown-locktype

mds: reply -EOPNOTSUPP for unknown lock type
Merge pull request #2711 from guangyy/wip-9614-followup

Follow-up fix for 9614

Reviewed-by: Samuel Just <sam.just@inktank.com>
Merge pull request #2708 from ceph/wip-9718

osd/osd_types: consider CRUSH_ITEM_NONE in check_new_interval() min_size

Reviewed-by: Samuel Just <sam.just@inktank.com>
qa/workunits: cephtool: don't remove self's key on auth tests

Suites run with CEPH_TEST_CLI_DUP_COMMAND=1, which will send a duplicate
command for every command issued with the 'ceph' tool.  Behavior is to
get a reply from the command and then send a duplicate, looking for the
same outcome (guaranteeing idempotency of the operations).  However, it
so happens that if you remove the entity's own key from the keyring and
you happen to be unlucky enough so that the client's connection gets
failed (we also run tests with connection failure injections), the
'ceph' tool won't be able to reconnect to the cluster to send the
duplicate command (as it's entity no longer exists in the cluster's
keyring).

We rewrite the test instead of resorting to ugly hacks to work around
this behavior, simply having a new 'role-definer' added by the existing
'role-definer' (which we weren't testing anyway, so bonus points for
that) and then have one removing the other (to test the procedure) and
finally using 'client.admin' to remove the last 'role-definer'.

Fixes: #9820

Signed-off-by: Joao Eduardo Luis <joao@redhat.com>
Merge pull request #2758 from ceph/wip-9820

qa/workunits: cephtool: don't remove self's key on auth tests

Reviewed-by: Sage Weil <sage@redhat.com>
Fix read performance regression in ObjectCacher

The regression was introduced in commit
4fc9fffc494abedac0a9b1ce44706343f18466f1.  The problem is that the cache
thinks it's full (when it's not), so it defers the read.  This change
frees up cache space if necessary and only defers the read if enough
space cannot be freed.

Fixes: 9513
Signed-off-by: Adam Crume <adamcrume@gmail.com>
(cherry picked from commit 82175ec94acc89dc75da0154f86187fb2e4dbf5e)
PG:: reset interval_flush and last_peering_reset in GetInfo, not Reset

If we have a change in the prior set, but not in the up/acting set, we go back
through Reset in order to reset peering state.  Previously, we would reset
last_peering_reset in the Reset constructor.  This did not, however, reset the
flush_interval, which caused the eventual flush event to be ignored and the
peering messages to not be sent.

We don't really want to reset the last_peering_interval in the Reset
constructor anyway since we always repost the AdvMap event causing
start_peering_interval() to fire in the Reset AdvMap handler.  That always
resets last_peering_reset and interval_flush anyway.  Instead, lets reset
last_peering_reset and interval_flush in GetInfo before transitioning to
Reset.

Fixes: #9821
Backport: firefly
Signed-off-by: Samuel Just <sam.just@inktank.com>