jvrao commented on a change in pull request #1138: BP-31 BookKeeper Durability 
URL: https://github.com/apache/bookkeeper/pull/1138#discussion_r168311642

 File path: site/bps/BP-31-durability
 @@ -0,0 +1,134 @@
+title: "BP-31: BookKeeper Durability(Anchor)"
+issue: https://github.com/apache/bookkeeper/BP-31-durability
+state: 'Anchor BP'
+release: "x.y.z"
+## Motivation
+Apache BookKeeper is transitioning into a full fledged distributed storage 
that can keep the data for long term. Durability is paramount to achieve the 
status of trusted store. This Anchor BP discusses many gaps and areas of 
improvement.  Each issue listed here will have another issue and this BP is 
expected to be updated when that issue is created.
+## Durability Contract
+1. **Maintain WQ copies all the time**. If any ledger falls into under 
replicated state, there needs to be an SLA on how quickly the replication 
levels can be brought back to normal levels.
+2. **Enforce Placement Policy** strictly during write and replication.
+3. **Protect the data** against corruption on the wire or at rest.
+## Work Grouping (In the order of priority)
+### Detect Durability Validation
+First step is to understand the areas of durability breaches. Design metrics 
that record durability contract violations. 
+* At the Creation: Validate durability contract the extent is being created
+* At the Deletion: Validate durability contract when extent is deleted
+* During lifetime: Validate durability contract during the lifetime of the 
extent.(periodic validator)
+* During Read: IO or Checksum errors in the read path
+### Delete Discipline
+* Build a single delete choke point with stringent validations
+* Archival bit in the metadata to assist Two phase Deletes
+* Stateful/Explicit Deletes
+### Metadata Recovery
+* Metadata recovery tool to reconstruct the metadata if the metadata server 
gets wiped out. This tool need to make sure that the data is readable even if 
we can't get all the metadata (ex: ctime) back.
+### Plug Durability Violations
+Our first step is to identify durability viloations. That gives us the 
magnitude of the problem and areas that we need to focus. In this phase, fix 
high impact areas.
+* Identify source of problems detected by the work we did in step-1 above 
(Detect Durability Validation)
+* Rereplicate under replicated extents detected during write
+* Rereplicate under replicated / corrupted extents detected during read
+* Replicated under replicated extents identified by periodic validator.
+### Durability Test
+* Test plan, new tests and integrating it into CI pipeline. 
+### Introduce bookie incarnation 
+* Design/Implement bookie incarnation mechanism 
+### End 2 End Checksum
+* Efficient checksum implementation (crc32c?)
 Review comment:
   crc32c is there, but I am not sure if we can't make any more changes to it. 
From @sijie 's numbers with crc32c is not a slamdunk. They are not great at 
lower payload size, even at 64k they are not negligible. So This is a BP will 
be to do more work in this area and come up with a method that has a negligible 

This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:

With regards,
Apache Git Services

Reply via email to