If the op has the RETURNVEC flag set,
- Record the per-op return value and overall return code in the pg log and
dup records.
- Include the same in the actual MOSDOpReply back to the client.
Signed-off-by: Sage Weil <sage@redhat.com>
This signals that the client is soliciting and expecting return codes
that are >0 and/or return buffers on update ops.
This should be used with caution, since it means that compound requests
that include read and write requests will *also* persist the read ops in
order to be idempotent, which means that those ops' results may get
truncated.
Signed-off-by: Sage Weil <sage@redhat.com>
There is no case where we have already allocated a reply message here,
since that is only done in execute_ctx() after the transaction is prepared,
something that doesn't happen if we proxy the write through to the base
layer.
Signed-off-by: Sage Weil <sage@redhat.com>
It is unclear why this path was originally needed, but it does predate
the removal of the dual-ack removal, so I expect it was related to
that. It is no longer necesarry.
Signed-off-by: Sage Weil <sage@redhat.com>
If our policy is server + lossy, we do not need to track our incoming
client connections by address. First, because it doesn't do us any good.
Second, it is nicer if we don't, because we can allow multiple incoming
connections from the same peer addr.
Update a couple of tests: one doesn't apply any more, and the other needs
a different way of getting the just-accepted con ref.
Signed-off-by: Sage Weil <sage@redhat.com>
If the connection mode is lossy, allow us to open a new connection to
a target, regardless of whether other such connections are already open.
This allows for single-use connections. If you call this multiple times,
you'll get separate, distinct connections.
We are lucky that the cleanup infrastructure for AsyncMessenger just works
without modification. :)
Signed-off-by: Sage Weil <sage@redhat.com>
* refs/pull/30523/head:
mon/MonClient: skip CEPHX_V2 challenge if client doesn't support it
Reviewed-by: Greg Farnum <gfarnum@redhat.com>
Reviewed-by: Ricardo Dias <rdias@suse.com>
Use the explicitly-passed cct here instead of relying on the global symbol.
The only user was check_health(), so this is easy.
Signed-off-by: Sage Weil <sage@redhat.com>
If we simplified a partially no-op pg_upmap_item, we shall still
continue to verify that the remaining part is valid.
The bug is introduced by 02e5499b35,
before which we always validate the correctness of a pg_upmap_item
before trying to cancel or simplify it.
Fixes: https://tracker.ceph.com/issues/42052
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
Spawn a bunch of threads, have them do a cluster_connect and immediately
shut the connection down again. Do this in a loop and allow the thread
to exit. Join all of the threads.
This helps ferret out places where state that is global to the program
is inadequately protected.
Test-for: https://tracker.ceph.com/issues/42026
Signed-off-by: Jeff Layton <jlayton@redhat.com>
If --force option is given along with an explicit list of issue numbers,
backport issues will be created regardless of issue status.
In all other usage scenarios, script behavior remains the same (backport
issues are created only if issue status is "Pending Backport").
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Also, skip the details about CephX user's keyring and monitor's socket
since the kernel driver can figure out these details automatically now.
Fixes: https://tracker.ceph.com/issues/41872
Signed-off-by: Rishabh Dave <ridave@redhat.com>
This achieves 2 things: makes it more understandable for the reader that
the boolean variable is an option and reads less like a method name.
Signed-off-by: Rishabh Dave <ridave@redhat.com>
Add an option "--clear-old-log" to get rid of log entries before making
entries for current batch of tests.
Signed-off-by: Rishabh Dave <ridave@redhat.com>
stdout of ps command is generally pretty huge which makes it harder to
interpret logs. Don't print it by default and add "--log-ps-output" to
enable printing it.
Signed-off-by: Rishabh Dave <ridave@redhat.com>
Override default timeout for execution of vstart.sh and stop.sh since
neither scripts take more than 100 seconds normally.
Signed-off-by: Rishabh Dave <ridave@redhat.com>
Add "--teardown" option so that vstart_runner.py tears down Ceph
cluster automatically after the batch of tests has completed running.
Also delete build/dev and build/out directories, after running stop.sh.
Update the doc for vstart_runner.py as well.
Signed-off-by: Rishabh Dave <ridave@redhat.com>
In all of these cases, the vector<OSDOp>* ops in question points to
the MOSDOp::ops vector, which is copied by the MOSDOpReply ctor.
Move back to a const MOSDOp* where appropropriate.
Signed-off-by: Sage Weil <sage@redhat.com>
`python3_pkgversion` is now defined as 3, while we don't have packages
like python3-Cython yet in EPEL7. but we do have `python36-Cython`. so
let's use `python3_version_nodots` instead.
Signed-off-by: Kefu Chai <kchai@redhat.com>
we still support Linux 3.10, which does not support `getrandom(2)`.
so even if the glibc installed on the building host offers `getentropy()`
call, we still need to check for the syscall's existence at runtime
in case that the Linux kernel version is lower than 3.17 which
introduced the support of `getrandom(2)`.
in this chance, we detect the existence of `getentropy()` by using it
when constructing `CryptoRandom`, this system call could fail due to 3
reasons:
1. ENOSYS: the kernel does not support `getrandom(2)`
2. EPERM: the syscall is blocked by a security policy
3. EINTR: interrupted by a signal
so we fall back to /dev/urandom in cases of ENOSYS and EPERM, retry on
EINTR, otherwise, an exception is thrown.
Fixes: https://tracker.ceph.com/issues/42018
Signed-off-by: Kefu Chai <kchai@redhat.com>
* refs/pull/29824/head:
qa: whitelist new FS_INLINE_DATA_DEPRECATED health warning
mds: add a HEALTH_WARN message when inline_data is enabled
mds: log a warning message when mds is started on an fs with inline_data
mon: deprecate CephFS inline_data support
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Reviewed-by: Douglas Fuller <dfuller@redhat.com>