Otherwise, AsyncConnection will use uninitialized feature to encode
message. The caller side will set a old version header but encode with newest
feature since passing feature is ok. It will let receiver side got a old
header version but newest payload decode result.
Signed-off-by: Haomai Wang <haomai@xsky.com>
In preparation to deglobalizing CephContext, remove the CephContext*
parameter to ceph_clock_now() and ceph::real_clock::now() that carries
a configurable offset.
Signed-off-by: Adam C. Emerson <aemerson@redhat.com>
Rollback slave operations is tricky. Make MDcache::request_kill
ignores request that has started slave operations.
Signed-off-by: Yan, Zheng <zyan@redhat.com>
trim_rollback_to was a not terrible name before in that all
it ever did is (possibly) trim the stashed version of the
object. However, now, it's going to encompass, in general,
the roll_forward part of a tpc (which will still be to
delete the stashed object in cases where that is
appropriate).
Signed-off-by: Samuel Just <sjust@redhat.com>
...and encode/decode it appropriately.
The idea of this field is to be advisory, to allow the MDS to handle
things differently if it so chooses. We deliberately do _not_ offer
any firm policy here.
We start with a flag that tells the MDS when an application may end up
blocking on the result of this cap request.
A new "sync" arg is added to send_cap, and we set the new flag in the
cap request based on its value. For now, the callers all set the sync
boolean to false everywhere to preserve the existing behavior.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
This ensures we reencode the payload with the
appropriate set of features if the client, us, or the
target do not have identical features. Otherwise we
may forward an encoding with more features than the
target can handle.
Signed-off-by: Sage Weil <sage@redhat.com>
When clang uses an 8 bit type for the enum, it
complains (out of range) if comparing <256,
and complains (tautological) if comparing <=256.
Avoid this by explicitly making the enum an
uint8_t, and just asserting that that it has
that size at the point that we assume so for
the encoding (in case someone modified the
type definition without checking how it was used).
Signed-off-by: John Spray <john.spray@redhat.com>
This was leaving garbage in some fields during decode
when decoding messages with an older version.
Fixes: http://tracker.ceph.com/issues/17466
Signed-off-by: John Spray <john.spray@redhat.com>
We were encoding the message with the sending client's
features, which makes no sense: we need to encode with
the recipient's features so that it can decode the
message.
The simplest way to fix this is to rip out the bizarre
msg_bl handling code and simply keep a decoded Message
reference, and encode it when we send.
We encode the encapsulated message with the intersection
of the target mon's features and the sending client's
features. This probably doesn't matter, but it's
conceivable that there is some feature-dependent
behavior in the message encode/decode that is important.
Fixes: http://tracker.ceph.com/issues/17365
Signed-off-by: Sage Weil <sage@redhat.com>
Change "is_failed" field to "flags" and use it to distinguish between timeout
and immediate, known OSD failure. Then use that in OSD and MON, and make sure
"min_reporters" don't affect known failures by actually going around failure
heuristic code.
Signed-off-by: Piotr Dałek <git@predictor.org.pl>
Back in 70094407c1 we require that anyone
encoding an OSDMap pass in a special feature bit indicating that they are
'enlightened' and understand the rules around encoding OSDMaps (basically,
only mons get to do it). We forgot to update MOSDMap, which may have to
reencode an OSDMap without some features to talk to a really old client.
We haven't noticed until now because the old set of features we had to do
this for are really old.
We are about to introduce new features (for addr2 encoding) that change
that, and this fix is needed to prevent an assert when doing a reencode.
Signed-off-by: Sage Weil <sage@redhat.com>
Unfortunately, the only option here is to rev the MClientRequest
version as the ceph_mds_request_head is not currently versioned. Add a
new ceph_mds_request_head, which contains a new ceph_mds_request_args
structure.
The new ceph_mds_request_head is now versioned via a __le16
at the beginning of it, and then the args structure is expanded to hold
the btime. When we get a legacy ceph_mds_request_head, we just set the
new fields to zero. When encoding a reply to a legacy client, we simply
don't encode the version in the head, or the btime in the setattr union
member.
Reluctantly-Signed-off-by: Jeff Layton <jlayton@redhat.com>
We're going to need to introduce new versions of these structures in
order to expand the setattr union member. Rename the existing ones so
that it's clear that they are for legacy clients and servers.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Currently we don't have a mechanism to set the btime, but we will need
that eventually. If we want to allow the client to cache that change, we
need to be able to pass it back and forth between client and server.
Signed-off-by: Jeff Layton <jlayton@redhat.com>