Project

General

Profile

Osd - Faster Peering » History » Version 5

Jessica Mack, 07/10/2015 09:59 PM

1 1 Jessica Mack
h1. Osd - Faster Peering
2
3
h3. Summary
4
5
For correctness reasons, peering requires a series of serial message transmissions and filestore syncs prior to completion.  This puts something of a lower bound on the latency client IO suffers on cluster change.
6
7
h3. Owners
8
9
* Sam Just (RedHat)
10
* Name (Affiliation)
11
* Name
12
13
h3. Interested Parties
14
15
* Guang Yang (Yahoo!)
16
* Name (Affiliation)
17
* Name
18
19
h3. Current Status
20
 
21
h3. Detailed Description
22
23 5 Jessica Mack
!{width:60%}graph.png!
24 1 Jessica Mack
25
The above is the peering state chart generated from the source.  GetInfo->GetLog->GetMissing requires three round trips to replicas.  First, we get pg infos from every osd in the prior set, acting set, and up set in order to choose an authoritative log.  Second, we fetch the authoritative log.  Last, we fetch missing sets from each acting set replica for use during recovery.
26
1) Can we preemptively request the log+missing for osds in the most recent prior set interval to hopefully skip the GetLog step?
27
2) Can we preemptively request the log+missing for acting and up osds in the GetInfo set to hopefully skip the GetMissing step?
28
 
29
Another wrinkle is that replicas do not send the info requested in GetInfo and the primary cannot start peering until the previous acting interval has been flushed.
30
1) We might be able to relax this to waiting for a commit (journal only) if we track unstable objects across intervals.  We need to track unstable objects for replicas going forward anyway to get replica reads right, so this might not be so bad.
31
32
h3. Work items
33
34
h4. Coding tasks
35
36
# Task 1
37
# Task 2
38
# Task 3
39
40
h4. Build / release tasks
41
42
# Task 1
43
# Task 2
44
# Task 3
45
46
h4. Documentation tasks
47
48
# Task 1
49
# Task 2
50
# Task 3
51
52
h4. Deprecation tasks
53
54
# Task 1
55
# Task 2
56
# Task 3