These are not added for dmcrypt right now because there is a bug related
to zapping encrypted disks that needs fixed first.
Signed-off-by: Andrew Schoen <aschoen@redhat.com>
Now that osd_id is passed to util.prepare.create_id it doesn't
make any sense to return osd_id from check_id anymore as it's
not being used.
Signed-off-by: Andrew Schoen <aschoen@redhat.com>
* refs/pull/19833/head:
common: add C_SaferCond ctor with name argument
Client: use C_SaferCond for "_flush_range"
client: use C_SaferCond for _fallocate and ll_write_block
client: use C_SaferCond for _sync_fs and _fsync
client: use C_SaferCond in Client::_write
client: use C_SaferCond for _read_sync
client: use C_SaferCond in _read_async
client: use C_SaferCond for "Client::_read"
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
* refs/pull/19836/head:
Avoid the assert failure when the inode for the cap_export from other MDS happened not in MDCache
Reviewed-by: Zheng Yan <zyan@redhat.com>
If you do not then auth will not be created for the new OSD and the
daemon will not be able to start.
Signed-off-by: Andrew Schoen <aschoen@redhat.com>
The prepare_filestore and prepare_bluestore methods do not need to
attempt to recreate osd_id or fsid because this happens in prepare
already.
Signed-off-by: Andrew Schoen <aschoen@redhat.com>
when reusing a thread-local std::ostream for a new log entry, clear any
ios flags (ie eofbit/failbit/badbit) that may have been set during its
previous use
without this, any stream errors (for example, passing a nullptr to
operator<< sets the badbit) will result in all log output on that thread
to be blank for the remainder of the process
Signed-off-by: Casey Bodley <cbodley@redhat.com>
With prefix_len initialized as zero, mask in netmask_ipv4/6()
will always be zero, so find_ip_in_subnet() always return the
first interface.
Set prefix_len to the right value to fetch the right interface.
Signed-off-by: Gu Zhongyan guzhongyan@360.cn
Signed-off-by: yupeng chen chenyupeng-it@360.cn
Old code does not set inode or dentry for rmsnap/renamesnap requests.
So rmsnap/renamesnap requests are sent to random mds.
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
MDCache::cow_inode() checks "cap->issued() & CEPH_CAP_ANY_WR" to decide
if it needs to setup need_snapflush for the new snapped inode.
Locker::handle_client_caps() should call Locker::_do_cap_update() first,
then update issued caps. Otherwise MDCache::cow_inode() will fail to
setup need_snapflush if cap messages flushes dirty caps and releases the
same caps.
Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
When building Ceph Debian installation package, libcephfs-test.jar
build would fail if multi junit versions are installed on the host.
In src/java/CMakeLists.txt, the "junit" search order is "junit"
and then "junit4". In case multi junit versions are installed,
the lower version (like 3.8) is found firstly, but junit4 is
required only. The search result will cause the failure.
Fix the issue by change search order to firstly search junit4
by default.
Fixes: http://tracker.ceph.com/issues/22828
Signed-off-by: Tone Zhang <tone.zhang@arm.com>