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 -- Mykola Golub _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
