We may also want to do the same for OSDs that are out and fully offloaded,
but that can wait until those OSDs go into a special "drive device to
failure" mode.
Signed-off-by: Sage Weil <sage@redhat.com>
On a quick look at the source code, I noticed this binary file, which
looks like was committed by mistake.
Signed-off-by: Cleber Rosa <crosa@redhat.com>
The HEAD and snapshots have potentially different flag states
since object maps get invalidated per revision.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
read_tags_until_next_message() will forward the ready future and create
a new promise for on_message, which assumes there is already a
read_message() holding the previous promise, but it is not true.
Signed-off-by: Yingxin <yingxin.cheng@intel.com>
__project_pg_history__ does an inverse traverse of the series
of osdmaps passed in to get a pg's pg_history_t filled, which
can become super inefficient if the osdmap list to check is
very long.
E.g., in one of our clusters, we've observed it took approximate
10s for a PG to finish it's projecting:
```
2018-08-27 13:51:58.694823 7f1e1335a700 15 osd.9 823276 project_pg_history 34.6e9 from 821893 to 823276, start ec=380829/380829 l
is/c 820412/820412 les/c/f 820413/820413/0 821785/821785/821785
2018-08-27 13:52:08.634230 7f1e1335a700 15 osd.9 823276 project_pg_history 34.6e9 acting|up changed in 822265 from [57]/[57] 57/5
7 -> [58,57]/[58,57] 58/58
2018-08-27 13:52:08.634244 7f1e1335a700 15 osd.9 823276 project_pg_history 34.6e9 up changed in 822265 from [57] 57 -> [58,57] 58
2018-08-27 13:52:08.634248 7f1e1335a700 15 osd.9 823276 project_pg_history 34.6e9 primary changed in 822265
2018-08-27 13:52:08.634250 7f1e1335a700 15 osd.9 823276 project_pg_history end ec=380829/380829 lis/c 820412/820412 les/c/f 82041
3/820413/0 822265/822265/822265
```
Quote from Sage:
> let's just kill this off entirely, and make the handle_pg_query_nopg
reply unconditionally. Or, maybe, do a single sloppy check to see if
the primary has changed since the original epoch... if the osdmap
happens to be in cache... or not.
The querying end will discard the reply if it is out of date from it's
perspective, so it doesn't matter, and I suspect the overhead of doing
the check is larger than the overhead of sending a query reply that gets ignored.
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
Signed-off-by: yanjun <yan.jun8@zte.com.cn>
This conflicts with the system assert.h so rename and change includes to
reflect the new name.
Fixes: http://tracker.ceph.com/issues/35682
Signed-off-by: Brad Hubbard <bhubbard@redhat.com>
This is used by bluestore fsck to ensure we're looking at the right
collection. It needs to validate both that the pool id matches the
object (including the temp objects) and that the hash matches; we were
only checking the hash before.
Fixes: http://tracker.ceph.com/issues/32731
Signed-off-by: Sage Weil <sage@redhat.com>
This could cause an assertion due to an access to uninitialized bloom
filter. This happened when detecting errors involving physical extents close to the end of a large partition.
E.g. it was observed in http://tracker.ceph.com/issues/25001 while trying to repair an OSD.
Fixes: https://tracker.ceph.com/issues/35971
Signed-off-by: Igor Fedotov <ifedotov@suse.com>
The rbd-mirror daemon will require permission to read config-keys
from the "rbd/mirror/" prefix. These new profiles (and the new
associated bootstrap-rbd-mirror user) provide the required
permissions.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
