There may also be issues with backfill listing objects in different
orders across primary and secondary shards. Sam, would this cause
correctness issues like potentially missing objects?
Josh
On 7/6/20 11:14 PM, Mykola Golub wrote:
And one more question. Is the issue with deep-scrub incorrectly
reporting missing shards the only problem that may be caused by
different ordering? Can anyone think of any potential problem that
might lead to a real data loss, e.g. when recovering an EC pg?
The cluster will eventually be migrated to the bluestore only, but the
migration process is long.
On Mon, Jul 06, 2020 at 01:33:03PM +0300, Mykola Golub wrote:
On Mon, Jul 06, 2020 at 09:13:58AM +0300, Mykola Golub wrote:
Looking at the cases we have it happens for objects that have the same
hash. When building the sorting key the bluestore escapes the object
name string, while the filestore sorts with the raw object name, which
may result in different order.
I left a note to the tracker ticket [1]. Actually it seems the
bluestor escapes the string incorrectly, which results in the order of
escaped strings is different than the order of not escaped ones.
But we can't just fix the bluestore escape function as the current
keys in db will become invalid.
[1] https://tracker.ceph.com/issues/43174#note-10
I pushed a PR for review that changes the sorting order for the
filestore [2]. Though using this solution would fix a cluster of mixed
bluestore and upgraded filestore osds but introduce the same issue for
a cluster of mixed old version and new version filestore osds.
[1] https://tracker.ceph.com/issues/43174
[2] https://github.com/ceph/ceph/pull/35938
--
Mykola Golub
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
