Skip to content

gofer: Support restore of deleted directories whose original path is occupied. #11843

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

Merged
merged 1 commit into from
Jul 16, 2025

Conversation

copybara-service[bot]
Copy link

@copybara-service copybara-service bot commented Jun 24, 2025

gofer: Support restore of deleted directories whose original path is occupied.

It is possible that the application can open an FD to a directory, delete the
directory, create another directory at that path and then checkpoint the
container. In such a scenario, our gofer restore logic will fail with EEXIST
because a directory already exists on the host at that location when we try to
recreate it.

Use a temporary filename to recreate the directory in such a scenario. This
directory is deleted again anyways.

This is similar to e3c4c4c ("gofer: Support restore of deleted files whose
original path is occupied.")

In addition to this, this change also makes the following bug fixes:

  • Adds a random suffix to the temporary filename used to recreate the file/dir.
    This helps if multiple (different) deleted open directories exist at the same
    position.
  • Change dentry.name for the duration of the restoreDeleted*() function. Note
    that dentry.restoreFile() use dentry.name to re-open handles and control FD.
    Hence setting the correct dentry.name is crucial for the handles to point to
    the correct file.
  • Added a syscall test, which when run in save/restore mode, tests these code
    paths for handling open deleted files/directories.

Updates #11425

@copybara-service copybara-service bot added the exported Issue was exported automatically label Jun 24, 2025
@copybara-service copybara-service bot force-pushed the test/cl775406486 branch 2 times, most recently from 8783b3e to 8d342f5 Compare July 16, 2025 06:01
…occupied.

It is possible that the application can open an FD to a directory, delete the
directory, create another directory at that path and then checkpoint the
container. In such a scenario, our gofer restore logic will fail with EEXIST
because a directory already exists on the host at that location when we try to
recreate it.

Use a temporary filename to recreate the directory in such a scenario. This
directory is deleted again anyways.

This is similar to e3c4c4c ("gofer: Support restore of deleted files whose
original path is occupied.")

In addition to this, this change also makes the following bug fixes:
- Adds a random suffix to the temporary filename used to recreate the file/dir.
  This helps if multiple (different) deleted open directories exist at the same
  position.
- Change dentry.name for the duration of the restoreDeleted*() function. Note
  that dentry.restoreFile() use dentry.name to re-open handles and control FD.
  Hence setting the correct dentry.name is crucial for the handles to point to
  the correct file.
- Added a syscall test, which when run in save/restore mode, tests these code
  paths for handling open deleted files/directories.

Updates #11425

PiperOrigin-RevId: 783627485
@copybara-service copybara-service bot merged commit 1282119 into master Jul 16, 2025
1 check was pending
@copybara-service copybara-service bot deleted the test/cl775406486 branch July 16, 2025 06:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exported Issue was exported automatically
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant