5 Jun
2019
5 Jun
'19
12:24 a.m.
Hi Xie,
Find my response inline.
On Mon, Jun 3, 2019 at 11:11 PM <xie.xingguo(a)zte.com.cn> 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?
>
>
>
>
>