Fixes: #5152
When iterating through usage entries, and when user id was
provided, we started at the user's first entry and not from
the entry indexed by the request start time.
This commit fixes the issue.
Backport: bobtail
Signed-off-by: Yehuda Sadeh <yehuda@inktank.com>
Reviewed-by: Greg Farnum <greg@inktank.com>
fixed bug in init script, the "df" should be run on remote host by do_cmd,
and use $host instead of "hostname -s"
Signed-off-by: Xiaoxi Chen <xiaoxi.chen@intel.com>
(cherry picked from commit 1dd99f0fc9)
Conflicts:
src/init-ceph.in
fixed bug in init script, the "df" should be run on remote host by do_cmd,
and use $host instead of "hostname -s"
Signed-off-by: Xiaoxi Chen <xiaoxi.chen@intel.com>
Send ping requests to both the front and back hb addrs for peer osds. If
the front hb addr is not present, do not send it and interpret a reply
as coming from both. This handles the transition from old to new OSDs
seamlessly.
Note both the front and back rx times. Both need to be up to date in order
for the peer to be healthy.
Signed-off-by: Sage Weil <sage@inktank.com>
The object would have had to have been removed already. With
fd caching, this extra remove might check the wrong replay_guard
since the fd caching mechanism assumes that between any operation
on an hobject_t oid and a remove operation, all operations on that
hobject_t must refer to the same inode.
Signed-off-by: Samuel Just <sam.just@inktank.com>
Fixes valgrind warning:
==14803== Use of uninitialised value of size 8
==14803== at 0x12E7614: sctp_crc32c_sb8_64_bit (sctp_crc32.c:567)
==14803== by 0x12E76F8: update_crc32 (sctp_crc32.c:609)
==14803== by 0x12E7720: ceph_crc32c_le (sctp_crc32.c:733)
==14803== by 0x105085F: ceph::buffer::list::crc32c(unsigned int) (buffer.h:427)
==14803== by 0x115D7B2: Message::calc_front_crc() (Message.h:441)
==14803== by 0x1159BB0: Message::encode(unsigned long, bool) (Message.cc:170)
==14803== by 0x1323934: Pipe::writer() (Pipe.cc:1524)
==14803== by 0x13293D9: Pipe::Writer::entry() (Pipe.h:59)
==14803== by 0x120A398: Thread::_entry_func(void*) (Thread.cc:41)
==14803== by 0x503BE99: start_thread (pthread_create.c:308)
==14803== by 0x6C6E4BC: clone (clone.S:112)
Backport: cuttlefish
Signed-off-by: Sage Weil <sage@inktank.com>
See #5031. This appears to be populated with another mds's mdsdir; just
not asserting avoids the problem for the time being.
Signed-off-by: Sage Weil <sage@inktank.com>
We need to do df on the remote host, not locally.
Simlarly, the ceph command uses the osd key, which exists remotely; run it there.
Signed-off-by: Sage Weil <sage@inktank.com>
We would need to do hostname -s on the remote node, not the local one.
But we already have $host; use it!
Reported-by: Xiaoxi Chen <xiaoxi.chen@intel.com>
Signed-off-by: Sage Weil <sage@inktank.com>
New pools won't be full. mon->pgmon()->pg_map.pg_pool_sum[poolid] will
implicitly create an entry for poolid causing register_new_pgs() to assume that
the newly created pgs in the new pool are in fact a result of a split
preventing MOSDPGCreate messages from being sent out.
Fixes: #4813
Backport: cuttlefish
Signed-off-by: Samuel Just <sam.just@inktank.com>
Reviewed-by: Sage Weil <sage@inktank.com>
