fix(buffers): disk buffers v2 reopen buffer after restart crash loop#25570
Open
blt wants to merge 2 commits into
Open
Conversation
Contributor
Author
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
This was referenced Jun 3, 2026
7b0865a to
db4960b
Compare
3614c5a to
5209ae6
Compare
db4960b to
e3cc97c
Compare
9 tasks
e3cc97c to
f6542c0
Compare
3cce5aa to
84df4d7
Compare
f6542c0 to
61e1f3e
Compare
| of failing the buffer build, so the buffer always reopens and continues delivering. | ||
|
|
||
| Disk buffer (v2) durability was also hardened: the directory holding the buffer is now | ||
| fsync'd after a data file is created. Previously only file contents were synced, so a |
6cf0d05 to
597b732
Compare
84df4d7 to
c066e34
Compare
597b732 to
b3c5011
Compare
8ff610c to
4811fb8
Compare
b3c5011 to
05d79f8
Compare
We have observed in Antithesis scenario `vector_to_vector_e2e_disk` that the disk buffer can be driven to a state where Vector will crash loop without recovery. This happens when the reader is set to resume from a data file that no longer exists and will not be created. Strictly, the disk buffer reader is meant to chase the writer. This happens because the deletion of completed data files is not atomic. When a reader finishes an acks a data file `delete_completed_data_file`: * unlinks the .dat file * advances the reader id in the ledger * fsyncs the ledger If Vector crashes after the unlink but before the ledger is fsync'ed this will cause the next instance of Vector to attempt to read a .dat that will never appear, crashing said instance. Mostly. OS page cache complicates this some, as the newly introduced `reopen_recovers_with_reader_resume_data_file_is_missing` discusses. REF SMPTNG-749
This commit fixes the crash-loop by carefully re-arranging when the ledger is updated and ensuring that directory metadata is also fsynced. This later is important as ledger still updates after the unlink takes place. If a file is gone we can assume that it has been read iff the ledger points to a new dat file, meaning that the data was previously read entirely and readers may skip the 'stale' reference. I have left this skip event as a warn! but considering how likely this is in practice in the event of node termination, for example, it might rightly be a debug. Overflow of dat file indexes remains a concern but 1. I would like to demonstrate this in an antithesis run and 2. that belongs in a separate commit.
05d79f8 to
fe305fa
Compare
4811fb8 to
85cfa4b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Summary
We have observed in Antithesis scenario
vector_to_vector_e2e_diskthatthe disk buffer can be driven to a state where Vector will crash loop
without recovery. This happens when the reader is set to resume from a
data file that no longer exists and will not be created.
Strictly, the disk buffer reader is meant to chase the writer. This
happens because the deletion of completed data files is not atomic. When
a reader finishes an acks a data file
delete_completed_data_file:If Vector crashes after the unlink but before the ledger is fsync'ed
this will cause the next instance of Vector to attempt to read a .dat
that will never appear, crashing said instance. Mostly. OS page cache
complicates this some, as the newly introduced
reopen_recovers_with_reader_resume_data_file_is_missingdiscusses.Vector configuration
How did you test this PR?
Change Type
Is this a breaking change?
Does this PR include user facing changes?
no-changeloglabel to this PR.References
Notes
@vectordotdev/vectorto reach out to us regarding this PR.pre-pushhook, please see this template.make fmtmake check-clippy(if there are failures it's possible some of them can be fixed withmake clippy-fix)make testgit merge origin masterandgit push.Cargo.lock), pleaserun
make build-licensesto regenerate the license inventory and commit the changes (if any). More details on the dd-rust-license-tool.