Skip to content

BlockFetch: wait until the block has been written to disk #1850

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 2 commits into from
Mar 25, 2020
Merged

BlockFetch: wait until the block has been written to disk #1850

merged 2 commits into from
Mar 25, 2020

Conversation

mrBliss
Copy link
Contributor

@mrBliss mrBliss commented Mar 25, 2020

Fixes #1845.

@mrBliss mrBliss added the consensus issues related to ouroboros-consensus label Mar 25, 2020
@mrBliss mrBliss requested review from nfrisby and dcoutts March 25, 2020 09:52
@mrBliss
Copy link
Contributor Author

mrBliss commented Mar 25, 2020

Alternatively, we also wait until the block has been processed by chain selection, which means we don't need the first commit. In that case, the use of addBlockWaitWrittenToDisk in the second commit should be replaced with addBlock. Also see IntersectMBO/ouroboros-consensus#760.

nfrisby
nfrisby approved these changes Mar 25, 2020
View reviewed changes
Copy link
Contributor

@nfrisby nfrisby left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGreatTM! One minor comment.

ouroboros-consensus/src/Ouroboros/Consensus/Storage/ChainDB/Impl/ChainSel.hs
@@ -251,18 +252,19 @@ addBlockSync cdb@CDB {..} BlockToAdd { blockToAdd = b, .. } = do
VolDB.putBlock cdbVolDB b
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This alternative currently delivers the WrittenToDisk promise after chain selection, whereas it could deliver it before. Is there a reason to favor one option over the other? "Promptness" of written-to-disk would favor changing this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're totally right, I glossed over it. I'll fix it.

nfrisby
nfrisby reviewed Mar 25, 2020
View reviewed changes
ouroboros-consensus/src/Ouroboros/Consensus/Storage/ChainDB/API.hs
@@ -332,7 +333,20 @@ instance DB (ChainDB m blk) where
-------------------------------------------------------------------------------}

data AddBlockPromise m blk = AddBlockPromise
{ blockProcessed :: STM m (Point blk)
{ blockWrittenToDisk :: STM m Bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One other minor comment: you've organized the new promise around "written to disk". Based on the code I'm seeing, it looks like "added to VolDB" would also be accurate. Just pointing that out, in case the less-specific name is appealing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I take your point. But IMO "written to disk" is fine.

mrBliss added 2 commits March 25, 2020 14:59
@mrBliss
ChainDB: add blockWrittenToDisk to AddBlockPromise
a751786 
This allows the caller to wait until the block has been written to disk (but
not yet processed by chain selection).
@mrBliss
BlockFetch: wait until the block has been written to disk
acea7f8 
Fixes #1845.
@mrBliss
Copy link
Contributor Author

mrBliss commented Mar 25, 2020

@nfrisby Could you verify that this actually fixes #1845 (maybe you have already)? I expect it does, but I haven't verified it myself.

@nfrisby
Copy link
Contributor

nfrisby commented Mar 25, 2020

@mrBliss Yes, it does what we expected. Basic test use two nodes, trace the BlockFetch client and BlockFetch decision for one node, inspect the output. Here's the diff in that output that I see by applying your fix.

10,17c10
< [TraceLabelPeer (CoreId (CoreNodeId 2)) (Right [At (Block {blockPointSlot = SlotNo {unSlotN
< TraceLabelPeer (CoreId (CoreNodeId 2)) (AddedFetchRequest (FetchRequest {fetchRequestFragme
< TraceLabelPeer (CoreId (CoreNodeId 2)) (CompletedFetchBatch (ChainRange (At (Block {blockPo
< TraceLabelPeer (CoreId (CoreNodeId 2)) (AcknowledgedFetchRequest (FetchRequest {fetchReques
< TraceLabelPeer (CoreId (CoreNodeId 2)) (StartedFetchBatch (ChainRange (At (Block {blockPoin
< [TraceLabelPeer (CoreId (CoreNodeId 2)) (Left FetchDeclineChainNotPlausible)]
< TraceLabelPeer (CoreId (CoreNodeId 2)) (CompletedBlockFetch (At (Block {blockPointSlot = Sl
< [TraceLabelPeer (CoreId (CoreNodeId 2)) (Left FetchDeclineChainNotPlausible)]
---
> [TraceLabelPeer (CoreId (CoreNodeId 2)) (Left FetchDeclineAlreadyFetched)]
18a12
> [TraceLabelPeer (CoreId (CoreNodeId 2)) (Left FetchDeclineAlreadyFetched)]
25,33c19
< [TraceLabelPeer (CoreId (CoreNodeId 2)) (Right [At (Block {blockPointSlot = SlotNo {unSlotN
< TraceLabelPeer (CoreId (CoreNodeId 2)) (AddedFetchRequest (FetchRequest {fetchRequestFragme
< TraceLabelPeer (CoreId (CoreNodeId 2)) (CompletedFetchBatch (ChainRange (At (Block {blockPo
< TraceLabelPeer (CoreId (CoreNodeId 2)) (AcknowledgedFetchRequest (FetchRequest {fetchReques
< TraceLabelPeer (CoreId (CoreNodeId 2)) (StartedFetchBatch (ChainRange (At (Block {blockPoin
< [TraceLabelPeer (CoreId (CoreNodeId 2)) (Left FetchDeclineChainNotPlausible)]
< TraceLabelPeer (CoreId (CoreNodeId 2)) (CompletedBlockFetch (At (Block {blockPointSlot = Sl
< [TraceLabelPeer (CoreId (CoreNodeId 2)) (Left FetchDeclineChainNotPlausible)]
< [TraceLabelPeer (CoreId (CoreNodeId 2)) (Left FetchDeclineChainNotPlausible)]
---
> [TraceLabelPeer (CoreId (CoreNodeId 2)) (Left FetchDeclineAlreadyFetched)]
34a21,22
> [TraceLabelPeer (CoreId (CoreNodeId 2)) (Left FetchDeclineAlreadyFetched)]
> [TraceLabelPeer (CoreId (CoreNodeId 2)) (Left FetchDeclineChainNotPlausible)]

Crucial observation: there are less AddedFetchRequest events.

@mrBliss
Copy link
Contributor Author

mrBliss commented Mar 25, 2020

Thanks for verifying it!

@mrBliss
Copy link
Contributor Author

mrBliss commented Mar 25, 2020

bors r+

@iohk-bors
Copy link
Contributor

iohk-bors bot commented Mar 25, 2020

Build succeeded

@iohk-bors iohk-bors bot merged commit d9d6c86 into master Mar 25, 2020
@iohk-bors iohk-bors bot deleted the mrBliss/fix-1845 branch March 25, 2020 15:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@nfrisby nfrisby nfrisby approved these changes

@dcoutts dcoutts Awaiting requested review from dcoutts

Assignees
No one assigned
Labels
consensus issues related to ouroboros-consensus
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Refine the BF logic for updating the PeerFetchState with async block adds
2 participants
@mrBliss @nfrisby