Most tools create the osd id before trying to start ceph-osd. Notably,
teuthology does not. We could fix that, but we would be changing behavior,
as the osd boot will happily create the osd id on the fly for us. Other
provisioning tools might rely on that behavior. Instead, just allocate
the id sooner in the process (if necessary).
Signed-off-by: Sage Weil <sage@redhat.com>
Update the crush location from ceph-osd instead of relying on
kludgey bash in ceph-osd-prestart.sh. Among other things, this
lets us get accurate statfs information from the ObjectStore
implementation instead of relying on 'df'.
Fixes: http://tracker.ceph.com/issues/15213
Signed-off-by: Sage Weil <sage@redhat.com>
The crush_location can come from an explicitly set config,
a hook, or a simple fabricated default (root=default host=...).
Signed-off-by: Sage Weil <sage@redhat.com>
Previously, fsx deleted all test data upon successful completion. Add
an option to leave the data behind for further analysis.
Signed-off-by: Douglas Fuller <dfuller@redhat.com>
This way we always return a safe upper bound on the amount of time
since we did a check. Among other things, this prevents us from
returning a value of 0, which is confusing.
Fixes: http://tracker.ceph.com/issues/15760
Signed-off-by: Sage Weil <sage@redhat.com>
1. write osd_uuid to omap dir when doing filestore mkfs
2. check if omap fsid matches osd fsid when doing filestore mount
(if there is no osd_uuid under omap, assume this as match)
Signed-off-by: Chendi.Xue <chendi.xue@intel.com>
In the HDD as OSD, SSD as journal test, we saw a great
throughput improvement if moving omap to a SSD device at
randwrite case.
This patch aim to add a config option 'filestore_omap_backend_path'
for users to configurate omap path before deploy.
Signed-off-by: Chendi Xue <chendi.xue@intel.com>
I found that, sometimes an OSD thread uses 100% CPU after cutting network
between OSD and client. recv(2) in Pipe::do_recv() keeps returning -EAGAIN,
which causes infinite loop. the call trace is:
Pipe::do_recv (...)
Pipe::buffered_recv (...)
Pipe::tcp_read_nonblocking (...)
Pipe::tcp_read (...)
Pipe::tcp_read() first calls Pipe::tcp_read_wait() to check if data is
avaliable. If there are prefetched data, Pipe::tcp_read_wait() return
immediately. Pipe::buffered_recv() is called, which reads data from the
prefetched data. If prefetched data isn't enough, Pipe::buffered_recv()
calls Pipe::do_recv() to read data from socket. But it's possble that
socket has no data at this time, so Pipe::do_recv() keeps retry.
The fix is simple, just not retry when recv(2) return -EAGAIN.
Fixes: #14120
Signed-off-by: Yan, Zheng <zyan@redhat.com>
dump_stuck_pg_stats() method returns either 0 on success or
an negative error code on failure. So it is wrong to reset
"r" to 0.
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
1. we automatically perform deep-scrub at osd_deep_scrub_interval,
not mon_scrub_interval(1week vs. 1day).
2. theoretically a pg can be in a combination state of both unscrubbed
and un-deep-scrubbed.
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
