Skip to content
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.

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

Do some best-effort cleanup in file backend #4684

Merged
merged 2 commits into from
Jun 4, 2018
Merged

Conversation

jefferai
Copy link
Member

@jefferai jefferai commented Jun 2, 2018

If put results in an encoding error and after the file is closed we
detect it's zero bytes, it could be caused by an out of space error on
the disk since file info is often stored in filesystem metadata with
reserved space. This tries to detect that scenario and perform
best-effort cleanup. We only do this on zero length files to ensure that
if an encode fails to write but the system hasn't already performed
truncation, we leave the existing data alone.

Vault should never write a zero-byte file (as opposed to a zero-byte
value in the encoded JSON) so if this case is hit it's always an error.

If put results in an encoding error and after the file is closed we
detect it's zero bytes, it could be caused by an out of space error on
the disk since file info is often stored in filesystem metadata with
reserved space. This tries to detect that scenario and perform
best-effort cleanup. We only do this on zero length files to ensure that
if an encode fails to write but the system hasn't already performed
truncation, we leave the existing data alone.

Vault should never write a zero-byte file (as opposed to a zero-byte
value in the encoded JSON) so if this case is hit it's always an error.
@jefferai jefferai added this to the 0.10.2 milestone Jun 2, 2018
// reserved.
fi, err := os.Stat(fullPath)
if err != nil {
return encErr
Copy link
Contributor

Choose a reason for hiding this comment

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

Since by this point we're in an questionable FS state, it may be useful to wrap/return both encErr and err.

Copy link
Member Author

Choose a reason for hiding this comment

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

The reason I didn't do that is I wasn't sure it was really meaningful to the user and might just confuse them if they don't realize that we've tried to do some things not specifically related to the original request. E.g. they do a write and get an error back saying that deletion failed.

@jefferai jefferai merged commit 58ac805 into master Jun 4, 2018
@jefferai jefferai deleted the file-cleanup-zero-bytes branch June 4, 2018 23:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants