Hi Xie, Find my response inline. On Mon, Jun 3, 2019 at 11:11 PM <xie.xingguo@xxxxxxxxxx> wrote: > > Josh & Neha, > > The partial recovery (https://github.com/ceph/ceph/pull/21722, I'd consider "incremental recovery" a better naming btw) > > has been merged into master a couple of weeks ago, which is great. > > However, I don't really like the way it tracing the modified content very much - it actually traces the unmodifed/clean parts of the specific object instead, > > which is neither straightforward nor super efficient. > > Can we change the design to record dirty regions instead? There should be two benefits I can think of by doing so: In order to do any kind of partial(or incremental) recovery we need to keep track of dirty/clean regions, the PR we merged chose to track clean regions. If you can make a case for using dirty regions instead by a) coming up with an implementation b) backing it up with reason and numbers that can prove that it is better, we'll be happy to take a look at it. > > 1、dirty_regions are smaller (should always be == clean_regions.size() - 1), which as a result can save us approximate > > 3000 (pg log entries) * 16 * 100 (100 pg per osd) = 4MB memory as well as bluestore.db space > > 2、we can re-use the existing modified_ranges of OpContext to trace the data regions modified by an op This sounds like a good idea to me. Thanks, Neha > > > What do you think? > > > > >
