Fix issue preventing reads after flush on a file handle #751
Conversation
This file contains 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
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
dannycjones
previously approved these changes
Feb 15, 2024
There was a problem hiding this comment.
LGTM.
Acknowledging trade-off that we mitigate the regression preventing reads after flush but introducing a race condition into file overwrites (available since v1.4.0 released this month) which could prevent opening a file for writing immediately after closing a file. (@passaro should we add an ignored test for this? I can add one in a follow-up PR.)
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
vladem
reviewed
Feb 15, 2024
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
passaro
had a problem deploying
to
PR integration tests
GitHub Actions
Failure
passaro
had a problem deploying
to
PR integration tests
GitHub Actions
Failure
dannycjones
had a problem deploying
to
PR integration tests
GitHub Actions
Failure
dannycjones
had a problem deploying
to
PR integration tests
GitHub Actions
Failure
dannycjones
had a problem deploying
to
PR integration tests
GitHub Actions
Failure
dannycjones
had a problem deploying
to
PR integration tests
GitHub Actions
Failure
Signed-off-by: Daniel Carl Jones <djonesoa@amazon.com>
dannycjones
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
dannycjones
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
dannycjones
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
dannycjones
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
dannycjones
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
dannycjones
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
dannycjones
had a problem deploying
to
PR integration tests
GitHub Actions
Error
dannycjones
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
dannycjones
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
dannycjones
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
dannycjones
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
dannycjones
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
dannycjones
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
dannycjones
temporarily deployed
to
PR integration tests
GitHub Actions
Inactive
vladem
approved these changes
Feb 16, 2024
There was a problem hiding this comment.
LGTM:
- flush() is no-op for read;
- inode readers counter is decremented on
release(accepted behaviour thatopenfor write following aclosemay fail for short period of time); - eager initialisation of file handles to avoid FH being readable when we already have a scheduled work to write to it
Merged
jamesbornholt
added a commit
to jamesbornholt/mountpoint-s3
that referenced
this pull request
Feb 27, 2024
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.
Description of change
Fix a regression introduced in 0030b0a where closing (
flush) a file descriptor would prevent subsequent reads on the corresponding file handle. The issue was caused byflushsetting the internal state of the file handle toClosedand decrementing the number of readers for the inode, which is used to disallow overwrites when there are open read file handles.This PR includes 2 main changes:
Closedstate and revertsflushto a no op for read file handles. The number of readers for an inode is decremented only onrelease.openeagerly discriminate between READ and WRITE, rather than on first read or write (or flush or release). This reverts the opposite change in Allow file overwrites #487 and allows to report error conditions onopenwhen appropriate rather than on subsequent operations.Relevant issues: #749
Does this change impact existing behavior?
Because
releaseis async, there is a race condition when trying to overwrite a file immediately after closing a read file handle on it, which results in the overwrite to occasionally fail on open.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and I agree to the terms of the Developer Certificate of Origin (DCO).