1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
|
=======================
Partial Object Recovery
=======================
Partial Object Recovery improves the efficiency of log-based recovery (vs
backfill). Original log-based recovery calculates missing_set based on pg_log
differences.
The whole object should be recovery from one OSD to another
if the object is indicated modified by pg_log regardless of how much
content in the object is really modified. That means a 4M object,
which is just modified 4k inside, should recovery the whole 4M object
rather than the modified 4k content. In addition, object map should be
also recovered even if it is not modified at all.
Partial Object Recovery is designed to solve the problem mentioned above.
In order to achieve the goals, two things should be done:
1. logging where the object is modified is necessary
2. logging whether the object_map of an object is modified is also necessary
class ObjectCleanRegion is introduced to do what we want.
clean_offsets is a variable of interval_set<uint64_t>
and is used to indicate the unmodified content in an object.
clean_omap is a variable of bool indicating whether object_map is modified.
new_object means that osd does not exist for an object
max_num_intervals is an upbound of the number of intervals in clean_offsets
so that the memory cost of clean_offsets is always bounded.
The shortest clean interval will be trimmed if the number of intervals
in clean_offsets exceeds the boundary.
etc. max_num_intervals=2, clean_offsets:{[5~10], [20~5]}
then new interval [30~10] will evict out the shortest one [20~5]
finally, clean_offsets becomes {[5~10], [30~10]}
Procedures for Partial Object Recovery
======================================
Firstly, OpContext and pg_log_entry_t should contain ObjectCleanRegion.
In do_osd_ops(), finish_copyfrom(), finish_promote(), corresponding content
in ObjectCleanRegion should mark dirty so that trace the modification of an object.
Also update ObjectCleanRegion in OpContext to its pg_log_entry_t.
Secondly, pg_missing_set can build and rebuild correctly.
when calculating pg_missing_set during peering process,
also merge ObjectCleanRegion in each pg_log_entry_t.
etc. object aa has pg_log:
26'101 {[0~4096, 8192~MAX], false}
26'104 {0~8192, 12288~MAX, false}
28'108 {[0~12288, 16384~MAX], true}
missing_set for object aa: merge pg_log above --> {[0~4096, 16384~MAX], true}.
which means 4096~16384 is modified and object_map is also modified on version 28'108
Also, OSD may be crash after merge log.
Therefore, we need to read_log and rebuild pg_missing_set. For example, pg_log is:
object aa: 26'101 {[0~4096, 8192~MAX], false}
object bb: 26'102 {[0~4096, 8192~MAX], false}
object cc: 26'103 {[0~4096, 8192~MAX], false}
object aa: 26'104 {0~8192, 12288~MAX, false}
object dd: 26'105 {[0~4096, 8192~MAX], false}
object aa: 28'108 {[0~12288, 16384~MAX], true}
Originally, if bb,cc,dd is recovered, and aa is not.
So we need to rebuild pg_missing_set for object aa,
and find aa is modified on version 28'108.
If version in object_info is 26'96 < 28'108,
we don't need to consider 26'104 and 26'101 because the whole object will be recovered.
However, Partial Object Recovery should also require us to rebuild ObjectCleanRegion.
Knowing whether the object is modified is not enough.
Therefore, we also need to traverse the pg_log before,
that says 26'104 and 26'101 also > object_info(26'96)
and rebuild pg_missing_set for object aa based on those three logs: 28'108, 26'104, 26'101.
The way how to merge logs is the same as mentioned above
Finally, finish the push and pull process based on pg_missing_set.
Updating copy_subset in recovery_info based on ObjectCleanRegion in pg_missing_set.
copy_subset indicates the intervals of content need to pull and push.
The complicated part here is submit_push_data
and serval cases should be considered separately.
what we need to consider is how to deal with the object data,
object data makes up of omap_header, xattrs, omap, data:
case 1: first && complete: since object recovering is finished in a single PushOp,
we would like to preserve the original object and overwrite on the object directly.
Object will not be removed and touch a new one.
issue 1: As object is not removed, old xattrs remain in the old object
but maybe updated in new object. Overwriting for the same key or adding new keys is correct,
but removing keys will be wrong.
In order to solve this issue, We need to remove the all original xattrs in the object, and then update new xattrs.
issue 2: As object is not removed,
object_map may be recovered depending on the clean_omap.
Therefore, if recovering clean_omap, we need to remove old omap of the object for the same reason
since omap updating may also be a deletion.
Thus, in this case, we should do:
1) clear xattrs of the object
2) clear omap of the object if omap recovery is needed
3) truncate the object into recovery_info.size
4) recovery omap_header
5) recovery xattrs, and recover omap if needed
6) punch zeros for original object if fiemap tells nothing there
7) overwrite object content which is modified
8) finish recovery
case 2: first && !complete: object recovering should be done in multiple times.
Here, target_oid will indicate a new temp_object in pgid_TEMP,
so the issues are a bit difference.
issue 1: As object is newly created, there is no need to deal with xattrs
issue 2: As object is newly created,
and object_map may not be transmitted depending on clean_omap.
Therefore, if clean_omap is true, we need to clone object_map from original object.
issue 3: As object is newly created, and unmodified data will not be transmitted.
Therefore, we need to clone unmodified data from the original object.
Thus, in this case, we should do:
1) remove the temp object
2) create a new temp object
3) set alloc_hint for the new temp object
4) truncate new temp object to recovery_info.size
5) recovery omap_header
6) clone object_map from original object if omap is clean
7) clone unmodified object_data from original object
8) punch zeros for the new temp object
9) recovery xattrs, and recover omap if needed
10) overwrite object content which is modified
11) remove the original object
12) move and rename the new temp object to replace the original object
13) finish recovery
|
