With change, librgw/rgw_file consumers can provide an invalidation
callback, which is used by the library to invalidate directories
whose contents should be forgotten.
The existing RGWLib GC mechanism is being used to drive this. New
configuration params have been added. The main configurable is
rgw_nfs_namespace_expire_secs, the expire timeout.
Updated post Yehuda review.
Fixes: http://tracker.ceph.com/issues/18651
Signed-off-by: Matt Benjamin <mbenjamin@redhat.com>
os/bluestore: fix NVMEDevice::open failure if serial number ends with a …
Reviewed-by: Haomai Wang <haomai@xsky.com>
Reviewed-by: Pan liu <liupan1111@gmail.com>
Reviewed-by: Igor Fedotov <ifedotov@mirantis.com>
Do not simply read the configuration value as it might have changed
during OSD startup by reading the type from disk.
Fixes: http://tracker.ceph.com/issues/18638
Signed-off-by: Wido den Hollander <wido@42on.com>
Having this too high means you might be more bursty. In practice,
though, the commit path is doing explicit syncs on small chunks
anyway. And compaction work should probably stay reasonably chunky.
Signed-off-by: Sage Weil <sage@redhat.com>
buf in effect is the serial number in ceph.conf and
the serial number consists of 16 hexadecimal characters.
1. In order to avoid ignoring the numbers, scan buf
with isxdigit.
2. In order to ignore all the potential garbage,
scan buf from the beginning.
Signed-off-by: Hongtong Liu <hongtong.liu@istuary.com>
the output on FreeBSD/clang looks like:
1: 0x44bfb3 <_Z3foov+0x413> at /usr/srcs/Ceph/work/ceph/build/bin/unittest_back_trace
2: 0x44c23e <_ZN20BackTrace_Basic_Test8TestBodyEv+0x1e> at /usr/srcs/Ceph/work/ceph/build/bin/unittest_back_trace
3: 0x4d068a <_ZN7testing8internal38HandleSehExceptionsInMethodIfSupportedINS_4TestEvEET0_PT_MS4_FS3_vEPKc+0x7a> at /usr/srcs/Ceph/work/ceph/build/bin/unittest_back_trace
4: 0x4b5977 <_ZN7testing8internal35HandleExceptionsInMethodIfSupportedINS_4TestEvEET0_PT_MS4_FS3_vEPKc+0x77> at /usr/srcs/Ceph/work/ceph/build/bin/unittest_back_trace
...
and update the test accordingly, as FreeBSD/clang uses '<>' to enclose
the mangled function and offset.
also, only demangle the C++ mangled names. those names always start with
"_Z". on FreeBSD, after demangling, "main" is turned into "unsigned
long", which does not make sense.
Signed-off-by: Kefu Chai <kchai@redhat.com>
It's possible that the future raced with its owner and reaches
an empty reference count. This was resulting in the future being
destructed while its lock was still held.
Fixes: http://tracker.ceph.com/issues/18618
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
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>
Expose public methods that include a new output argument to indicate
whether there are more keys to fetch or not.
Mark the old interfaces deprecated.
Signed-off-by: Sage Weil <sage@redhat.com>
If we do not get an explicit 'more' value from the OSD, infer it by
checking whether we got the max requested entries. On old OSDs, which
don't enforce a limit, this will work. On new OSDs, we will get the
explicit result.
Signed-off-by: Sage Weil <sage@redhat.com>
