client: cast m->get_client_tid() to compare to 16-bit Inode::flushing_cap_tid

m->get_client_tid() is 64 bits (as it should be), but Inode::flushing_cap_tid
is only 16 bits. 16 bits should be plenty to let the cap flush updates
pipeline appropriately, but we need to cast in the proper direction when
comparing these differently-sized versions. So downcast the 64-bit one
to 16 bits.

Fixes: #9869
Backport: giant, firefly, dumpling

Signed-off-by: Greg Farnum <greg@inktank.com>
(cherry picked from commit a5184cf46a6e867287e24aeb731634828467cd98)
Merge pull request #2840 from ceph/firefly-9869

Backport "client: cast m->get_client_tid() to compare to 16-bit Inode::flushing_cap_tid"
osd: past_interval display bug on acting

The acting array was incorrectly including the primary and up_primary.

http://tracker.ceph.com/issues/9752 Fixes: #9752

Signed-off-by: Loic Dachary <loic-201408@dachary.org>
(cherry picked from commit c5f8d6eded52da451fdd1d807bd4700221e4c41c)
Merge pull request #2847 from dachary/wip-9752-past-intervals-firefly

osd: past_interval display bug on acting
rgw: subuser creation fixes

Fixes: #8587
There were a couple of issues, one when trying to identify whether swift
user exists, we weren't using the correct swift id. The second problem
is that we relied on the gen_access flag in the swift case, where it
doesn't really need to apply.

Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
(cherry picked from commit 1441ffe8103f03c6b2f625f37adbb2e1cfec66bb)
rgw: set length for keystone token validation request

Fixes: #7796
Backport: giany, firefly
Need to set content length to this request, as the server might not
handle a chunked request (even though we don't send anything).

Tested-by: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
Signed-off-by: Yehuda Sadeh <yehuda@redhat.com>
(cherry picked from commit 3dd4ccad7fe97fc16a3ee4130549b48600bc485c)
ceph-disk: mount xfs with inode64 by default

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>
(cherry picked from commit 11496399ef318498c11e551f139d96db52d3309c)
Merge pull request #2776 from ceph/wip-9675.firefly

CrushWrapper: pick a ruleset same as rule_id

Reviewed-by: Samuel Just <sam.just@inktank.com>
Merge pull request #2764 from ceph/wip-9851

osd: bring FileJournal in sync with giant

Reviewed-by: Samuel Just <sjust@redhat.com>
Merge pull request #2656 from ceph/wip-9502-firefly

mon: backport mon disk full check to firefly

Reviewed-by: Samuel Just <sjust@redhat.com>
Merge pull request #2657 from ceph/wip-9053-9301-firefly

mon: backport two paxos fixes to firefly

Reviewed-by: Joao Luis <joao@redhat.com>
Merge pull request #2737 from ceph/wip-9629-firefly

osd: do not clone/preserve snapdir on cache-evict (firefly backport)

Reviewed-by: Samuel Just <sjust@redhat.com>
Merge remote-tracking branch 'origin/wip-sam-firefly-backports' into firefly
tools: fix MDS journal import

Previously it only worked on fresh filesystems which
hadn't been trimmed yet, and resulted in an invalid
trimmed_pos when expire_pos wasn't on an object
boundary.

Fixes: #10025

Signed-off-by: John Spray <john.spray@redhat.com>
(cherry picked from commit fb29e71f9a97c12354045ad2e128156e503be696)
Merge pull request #2880 from ceph/wip-10025-firefly

#10025/firefly -- tools: fix MDS journal import

Reviewed-by: Greg Farnum <greg@inktank.com>
osd: fix map advance limit to handle map gaps

The recent change in cf25bdf6b0090379903981fe8cee5ea75efd7ba0 would stop
advancing after some number of epochs, but did not take into consideration
the possibilty that there are missing maps.  In that case, it is impossible
to advance past the gap.

Fix this by increasing the max epoch as we go so that we can always get
beyond the gap.

Signed-off-by: Sage Weil <sage@inktank.com>
(cherry picked from commit 1e0a82fd55dede473c0af32924f4bcb5bb697a2b)
qa: allow small allocation diffs for exported rbds

The local filesytem may behave slightly differently. This isn't
foolproof, but seems to be reliable enough on rhel7 rootfs, where
exact comparison was failing.

Fixes: #10002
Signed-off-by: Josh Durgin <jdurgin@redhat.com>
(cherry picked from commit e94d3c11edb9c9cbcf108463fdff8404df79be33)
osd/OSDMap: add osd_is_valid_op_target()

Helper to check whether an osd is a given op target for a pg.  This
assumes that for EC we always send ops to the primary, while for
replicated we may target any replica.

Signed-off-by: Sage Weil <sage@redhat.com>
(cherry picked from commit 89c02637914ac7332e9dbdbfefc2049b2b6c127d)
osd: discard rank > 0 ops on erasure pools

Erasure pools do not support read from replica, so we should drop
any rank > 0 requests.

This fixes a bug where an erasure pool maps to [1,2,3], temporarily maps
to [-1,2,3], sends a request to osd.2, and then remaps back to [1,2,3].
Because the 0 shard never appears on osd.2, the request sits in the
waiting_for_pg map indefinitely and cases slow request warnings.
This problem does not come up on replicated pools because all instances of
the PG are created equal.

Fix by only considering role == 0 for erasure pools as a correct mapping.

Fixes: #9835
Signed-off-by: Sage Weil <sage@redhat.com>
osd: use OSDMap helper to tell if ops are misdirected

calc_pg_role doesn't actually take into account primary affinity.

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