mirror of
https://github.com/ceph/ceph
synced 2024-12-18 17:37:38 +00:00
1d9668cd0e
Signed-off-by: John Spray <john.spray@redhat.com>
48 lines
2.5 KiB
Plaintext
48 lines
2.5 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.
|
|
|
|
* When configuring ceph-fuse mounts in /etc/fstab, a new syntax is
|
|
available that uses "ceph.<arg>=<val>" in the options column, instead
|
|
of putting configuration in the device column. The old style syntax
|
|
still works. See the documentation page "Mount CephFS in your
|
|
file systems table" for details.
|
|
|