This is based out of Doug's (@fullerdj) work (PR #9329)
as an attempt to avoid creating empty objects when
flattening an image and otherwise whenever unnecessary.
This gives good optimization benefit when a parent image
is sparsely populated. Moreover, this change is required
for correct behavior when checking disk usage of a clone
(which used to report fully allocated image due to all,
including empty objects being created during flatten).
Signed-off-by: Douglas Fuller dfuller@redhat.com
Signed-off-by: Venky Shankar <vshankar@redhat.com>
This is required when CopyupRequest would need to invoke
pre_object_map_update() as part of upcoming changes to
create fewer child image objects whenever possible.
CopyupRequest constructor accepts image extents as an
rvalue forcing the caller to transfer ownership to it
and leaving the original variable in an unspecified
stated making has_parent() return incorrect state when
invoked from CopyupRequest. Therefore, introduce a
private tracking state that can be used in place of
checking emptiness of parent image extents.
Signed-off-by: Venky Shankar <vshankar@redhat.com>
An allocation of size 0x80000000 gets truncated to 0. Larger values can
break things in similar ways.
Introduced in 5ab034345d.
Fixes: http://tracker.ceph.com/issues/18595
Signed-off-by: Sage Weil <sage@redhat.com>
the dirfrag can be migareted to other mds while waiting in the
timer.
Fixes: http://tracker.ceph.com/issues/18487
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
This commit clarifies that folks opening bugfix PRs that need backporting to
one or more stable branches should always target master, and that the
backporting itself takes place only after the master PR is merged.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Before this patch the flag was wrongly handled in the Swift API
implementation. In rare conditions this might result in setting
req_state::system_request.
This may happen only if both of those conditions are fulfilled:
* RadosGW is running in a multi-site configuration (at least
one user with the system flag turned on is present),
* the "rgw_swift_account_in_url" configurable has been switched
to true. The value is false by default and our documentation
doesn't actually mention about the option.
The issue doesn't affect Jewel nor any previous release.
Fixes: http://tracker.ceph.com/issues/18476
Signed-off-by: Radoslaw Zarzynski <rzarzynski@mirantis.com>
The call is cognate to removed code in radosgw, and triggers an
assert that the crypto module has already been shutdown. With this
and preceding changes, I see clean shutdown on abnormal termination
of nfs-ganesha during startup.
Fixes: http://tracker.ceph.com/issues/18585
Signed-off-by: Matt Benjamin <mbenjamin@redhat.com>
In some librgw shutdown cases, it appears that the shared
object runtime has partially destructed the static map when
our shutdown code is running.
Fixes: http://tracker.ceph.com/issues/18585
Signed-off-by: Matt Benjamin <mbenjamin@redhat.com>
Instead of having a separate output argument with the number of
blocks allocated, just return it via the return value. Simplifies
the calling convention.
Signed-off-by: Sage Weil <sage@redhat.com>
ExtentList was previous relying the caller to preallocate/size the
vector to be large enough for the worst case allocation of extents,
and keeping it's own manual count of the extent list size. Instead,
manage that from ExtentList, and remove the preallocation from the
callers.
Fixes: http://tracker.ceph.com/issues/18573
Signed-off-by: Sage Weil <sage@redhat.com>
os/bluestore: avoid unnecessary memory copy, use variable reference in BlockDevice::Open
Reviewed-by: Sage Weil <sage@redhat.com>
Reviewed-by: Igor Fedotov <ifedotov@mirantis.com>
The problem was due to the attempt of CMake to rewrite the RPATH of
the executables, or shared libraries, that didn't have any RPATH linked
during the building phase.
Currently INSTALL_RPATH is already set for all binaries. This patch
sets an empty INSTALL_RPATH for all binaries that don't depend on
any internal (also being built) target.
Signed-off-by: Ricardo Dias <rdias@suse.com>
