mirror of
https://github.com/ceph/ceph
synced 2024-12-19 01:46:00 +00:00
923e7f5ce5
In practice this tends to get bubbled up the stack as an error on the caller, and they usually do not handle it properly. For example, with librbd, this turns into EIO and break the VM. Instead, this will manifest as a hung op on the client. That is also not ideal, but given that the root cause here is generally a bug, it's not clear what else would be better. We already log an error in the cluster log, so teuthology runs will continue to fail. Signed-off-by: Sage Weil <sage@redhat.com>
41 lines
2.2 KiB
Plaintext
41 lines
2.2 KiB
Plaintext
12.0.0
|
|
------
|
|
|
|
* When assigning a network to the public network and not to
|
|
the cluster network the network specification of the public
|
|
network will be used for the cluster network as well.
|
|
In older versions this would lead to cluster services
|
|
being bound to 0.0.0.0:<port>, thus making the
|
|
cluster service even more publicly available than the
|
|
public services. When only specifying a cluster network it
|
|
will still result in the public services binding to 0.0.0.0.
|
|
|
|
* Some variants of the omap_get_keys and omap_get_vals librados
|
|
functions have been deprecated in favor of omap_get_vals2 and
|
|
omap_get_keys2. The new methods include an output argument
|
|
indicating whether there are additional keys left to fetch.
|
|
Previously this had to be inferred from the requested key count vs
|
|
the number of keys returned, but this breaks with new OSD-side
|
|
limits on the number of keys or bytes that can be returned by a
|
|
single omap request. These limits were introduced by kraken but
|
|
are effectively disabled by default (by setting a very large limit
|
|
of 1 GB) because users of the newly deprecated interface cannot
|
|
tell whether they should fetch more keys or not. In the case of
|
|
the standalone calls in the C++ interface
|
|
(IoCtx::get_omap_{keys,vals}), librados has been updated to loop on
|
|
the client side to provide a correct result via multiple calls to
|
|
the OSD. In the case of the methods used for building
|
|
multi-operation transactions, however, client-side looping is not
|
|
practical, and the methods have been deprecated. Note that use of
|
|
either the IoCtx methods on older librados versions or the
|
|
deprecated methods on any version of librados will lead to
|
|
incomplete results if/when the new OSD limits are enabled.
|
|
|
|
* In previous versions, if a client sent an op to the wrong OSD, the OSD
|
|
would reply with ENXIO. The rationale here is that the client or OSD is
|
|
clearly buggy and we want to surface the error as clearly as possible.
|
|
We now only send the ENXIO reply if the osd_enxio_on_misdirected_op option
|
|
is enabled (it's off by default). This means that a VM using librbd that
|
|
previously would have gotten an EIO and gone read-only will now see a
|
|
blocked/hung IO instead.
|