On Thu, Aug 23, 2018 at 8:38 AM, poi <poiiiicen@xxxxxxxxx> wrote: > Hello! > > Recently, we did data migration from one crush root to another, but > after that, we found some objects were wrong and their copies on other > OSDs were also wrong. > > Finally, we found that for one pg, the data migration uses only one > OSD's data to generate three new copies, and do not check the crc > before migration like assuming the data is always correct (but > actually nobody can promise it). We tried both filestore and > bluestore, and the results were the same. Copying from one pg without > crc check may lack reliability. Exactly what version are you running, and what backends? Are you actually using BlueStore? This is certainly the general case with replicated pools on FileStore, but it shouldn't happen with BlueStore or EC pools at all. We aren't going to implement "voting" on FileStore-backed OSDs though as that would vastly multiply the cost of backfilling. :( -Greg > > Is there any way to ensure the correctness of data when data > migration? Although we can do deep scrub before migration, but the > cost is too high. I think when peering, adding crc check for objects > before copying may work. > > Regards > > Poi
