Repository navigation
Pass host inode numbers through the gofer client - #16469
Merged
copybara-service[bot] merged 1 commit intoOct 29, 2026
Merged
Conversation
ayushr2
force-pushed
the
gofer-ino-passthrough
branch
2 times, most recently
from
October 28, 2026 00:04
aa69c5a to
d2ab214
Compare
ayushr2
marked this pull request as ready for review
October 28, 2026 03:44
EtiennePerot
approved these changes
Oct 28, 2026
ayushr2
force-pushed
the
gofer-ino-passthrough
branch
3 times, most recently
from
October 28, 2026 05:55
fcb35e7 to
271e52f
Compare
EtiennePerot
approved these changes
Oct 28, 2026
copybara-service Bot
pushed a commit
that referenced
this pull request
Oct 28, 2026
The gofer client assigns every file an inode number from a map keyed by the file's host device and inode numbers. The map gains an entry for every file the sandbox has ever looked up or listed and is never pruned, so sentry memory grows with the number of files seen: about 100 B of RSS per file, or 100 MiB for the life of the sandbox after a find over 1M files. Workspaces on host tmpfs never reuse inode numbers, so long-running sandboxes grow without bound. The key also makes getdents(2) stat(2) every entry to learn its device number. Report host inode numbers as is instead, and map host device numbers to sandbox-private device numbers, as Linux overlayfs does. Synthetic files keep sequential inode numbers on the filesystem's own device number, so they cannot collide with host files. getdents(2) no longer stats entries, neither on directfs nor in the gofer process. Across checkpoint/restore, inode numbers follow the host files, and the device number saved for a host device is reused for the device on which restored files are found. Device and inode numbers are therefore stable across restore when the backing files are unchanged, for all files rather than only those with an open FD. Conversely, inode numbers of files with an open FD may change if the backing filesystem changed, as they already do for other files. --inode-numbers=virtual keeps the previous behavior. Fixes #6665 Fixes #10047 Fixes #16197 FUTURE_COPYBARA_INTEGRATE_REVIEW=#16469 from ayushr2:gofer-ino-passthrough 271e52f PiperOrigin-RevId: 1008619002
copybara-service Bot
pushed a commit
that referenced
this pull request
Oct 28, 2026
The gofer client assigns every file an inode number from a map keyed by the file's host device and inode numbers. The map gains an entry for every file the sandbox has ever looked up or listed and is never pruned, so sentry memory grows with the number of files seen: about 100 B of RSS per file, or 100 MiB for the life of the sandbox after a find over 1M files. Workspaces on host tmpfs never reuse inode numbers, so long-running sandboxes grow without bound. The key also makes getdents(2) stat(2) every entry to learn its device number. Report host inode numbers as is instead, and map host device numbers to sandbox-private device numbers, as Linux overlayfs does. Synthetic files keep sequential inode numbers on the filesystem's own device number, so they cannot collide with host files. getdents(2) no longer stats entries, neither on directfs nor in the gofer process. Across checkpoint/restore, inode numbers follow the host files, and the device number saved for a host device is reused for the device on which restored files are found. Device and inode numbers are therefore stable across restore when the backing files are unchanged, for all files rather than only those with an open FD. Conversely, inode numbers of files with an open FD may change if the backing filesystem changed, as they already do for other files. --inode-numbers=virtual keeps the previous behavior. Fixes #6665 Fixes #10047 Fixes #16197 FUTURE_COPYBARA_INTEGRATE_REVIEW=#16469 from ayushr2:gofer-ino-passthrough 271e52f PiperOrigin-RevId: 1008619002
copybara-service Bot
pushed a commit
that referenced
this pull request
Oct 28, 2026
The gofer client assigns every file an inode number from a map keyed by the file's host device and inode numbers. The map gains an entry for every file the sandbox has ever looked up or listed and is never pruned, so sentry memory grows with the number of files seen: about 100 B of RSS per file, or 100 MiB for the life of the sandbox after a find over 1M files. Workspaces on host tmpfs never reuse inode numbers, so long-running sandboxes grow without bound. The key also makes getdents(2) stat(2) every entry to learn its device number. Report host inode numbers as is instead, and map host device numbers to sandbox-private device numbers, as Linux overlayfs does. Synthetic files keep sequential inode numbers on the filesystem's own device number, so they cannot collide with host files. getdents(2) no longer stats entries, neither on directfs nor in the gofer process. Across checkpoint/restore, inode numbers follow the host files, and the device number saved for a host device is reused for the device on which restored files are found. Device and inode numbers are therefore stable across restore when the backing files are unchanged, for all files rather than only those with an open FD. Conversely, inode numbers of files with an open FD may change if the backing filesystem changed, as they already do for other files. --inode-numbers=virtual keeps the previous behavior. Fixes #6665 Fixes #10047 Fixes #16197 FUTURE_COPYBARA_INTEGRATE_REVIEW=#16469 from ayushr2:gofer-ino-passthrough 271e52f PiperOrigin-RevId: 1008619002
Collaborator
|
Build failure: |
The gofer client assigns every file an inode number from a map keyed by the file's host device and inode numbers. The map gains an entry for every file the sandbox has ever looked up or listed and is never pruned, so sentry memory grows with the number of files seen: about 100 B of RSS per file, or 100 MiB for the life of the sandbox after a find over 1M files. Workspaces on host tmpfs never reuse inode numbers, so long-running sandboxes grow without bound. The key also makes getdents(2) stat(2) every entry to learn its device number. Report host inode numbers as is instead, and map host device numbers to sandbox-private device numbers, as Linux overlayfs does. Synthetic files keep sequential inode numbers on the filesystem's own device number, so they cannot collide with host files. getdents(2) no longer stats entries, neither on directfs nor in the gofer process. Across checkpoint/restore, inode numbers follow the host files, and the device number saved for a host device is reused for the device on which restored files are found. Device and inode numbers are therefore stable across restore when the backing files are unchanged, for all files rather than only those with an open FD. Conversely, inode numbers of files with an open FD may change if the backing filesystem changed, as they already do for other files. --inode-numbers=virtual keeps the previous behavior. Fixes google#6665 Fixes google#10047 Fixes google#16197
ayushr2
force-pushed
the
gofer-ino-passthrough
branch
from
October 28, 2026 19:08
271e52f to
8ead67b
Compare
Collaborator
Author
|
@EtiennePerot done |
EtiennePerot
approved these changes
Oct 28, 2026
copybara-service Bot
pushed a commit
that referenced
this pull request
Oct 28, 2026
The gofer client assigns every file an inode number from a map keyed by the file's host device and inode numbers. The map gains an entry for every file the sandbox has ever looked up or listed and is never pruned, so sentry memory grows with the number of files seen: about 100 B of RSS per file, or 100 MiB for the life of the sandbox after a find over 1M files. Workspaces on host tmpfs never reuse inode numbers, so long-running sandboxes grow without bound. The key also makes getdents(2) stat(2) every entry to learn its device number. Report host inode numbers as is instead, and map host device numbers to sandbox-private device numbers, as Linux overlayfs does. Synthetic files keep sequential inode numbers on the filesystem's own device number, so they cannot collide with host files. getdents(2) no longer stats entries, neither on directfs nor in the gofer process. Across checkpoint/restore, inode numbers follow the host files, and the device number saved for a host device is reused for the device on which restored files are found. Device and inode numbers are therefore stable across restore when the backing files are unchanged, for all files rather than only those with an open FD. Conversely, inode numbers of files with an open FD may change if the backing filesystem changed, as they already do for other files. --inode-numbers=virtual keeps the previous behavior. Fixes #6665 Fixes #10047 Fixes #16197 Auto-fixed-by: [🤖] @EtiennePerot FUTURE_COPYBARA_INTEGRATE_REVIEW=#16469 from ayushr2:gofer-ino-passthrough 271e52f PiperOrigin-RevId: 1008751258
parth-opensrc
approved these changes
Oct 28, 2026
copybara-service Bot
pushed a commit
that referenced
this pull request
Oct 28, 2026
The gofer client assigns every file an inode number from a map keyed by the file's host device and inode numbers. The map gains an entry for every file the sandbox has ever looked up or listed and is never pruned, so sentry memory grows with the number of files seen: about 100 B of RSS per file, or 100 MiB for the life of the sandbox after a find over 1M files. Workspaces on host tmpfs never reuse inode numbers, so long-running sandboxes grow without bound. The key also makes getdents(2) stat(2) every entry to learn its device number. Report host inode numbers as is instead, and map host device numbers to sandbox-private device numbers, as Linux overlayfs does. Synthetic files keep sequential inode numbers on the filesystem's own device number, so they cannot collide with host files. getdents(2) no longer stats entries, neither on directfs nor in the gofer process. Across checkpoint/restore, inode numbers follow the host files, and the device number saved for a host device is reused for the device on which restored files are found. Device and inode numbers are therefore stable across restore when the backing files are unchanged, for all files rather than only those with an open FD. Conversely, inode numbers of files with an open FD may change if the backing filesystem changed, as they already do for other files. --inode-numbers=virtual keeps the previous behavior. Fixes #6665 Fixes #10047 Fixes #16197 FUTURE_COPYBARA_INTEGRATE_REVIEW=#16469 from ayushr2:gofer-ino-passthrough 8ead67b PiperOrigin-RevId: 1009090814
copybara-service Bot
pushed a commit
that referenced
this pull request
Oct 28, 2026
The gofer client assigns every file an inode number from a map keyed by the file's host device and inode numbers. The map gains an entry for every file the sandbox has ever looked up or listed and is never pruned, so sentry memory grows with the number of files seen: about 100 B of RSS per file, or 100 MiB for the life of the sandbox after a find over 1M files. Workspaces on host tmpfs never reuse inode numbers, so long-running sandboxes grow without bound. The key also makes getdents(2) stat(2) every entry to learn its device number. Report host inode numbers as is instead, and map host device numbers to sandbox-private device numbers, as Linux overlayfs does. Synthetic files keep sequential inode numbers on the filesystem's own device number, so they cannot collide with host files. getdents(2) no longer stats entries, neither on directfs nor in the gofer process. Across checkpoint/restore, inode numbers follow the host files, and the device number saved for a host device is reused for the device on which restored files are found. Device and inode numbers are therefore stable across restore when the backing files are unchanged, for all files rather than only those with an open FD. Conversely, inode numbers of files with an open FD may change if the backing filesystem changed, as they already do for other files. --inode-numbers=virtual keeps the previous behavior. Fixes #6665 Fixes #10047 Fixes #16197 FUTURE_COPYBARA_INTEGRATE_REVIEW=#16469 from ayushr2:gofer-ino-passthrough 8ead67b PiperOrigin-RevId: 1009090814
copybara-service Bot
pushed a commit
that referenced
this pull request
Oct 28, 2026
The gofer client assigns every file an inode number from a map keyed by the file's host device and inode numbers. The map gains an entry for every file the sandbox has ever looked up or listed and is never pruned, so sentry memory grows with the number of files seen: about 100 B of RSS per file, or 100 MiB for the life of the sandbox after a find over 1M files. Workspaces on host tmpfs never reuse inode numbers, so long-running sandboxes grow without bound. The key also makes getdents(2) stat(2) every entry to learn its device number. Report host inode numbers as is instead, and map host device numbers to sandbox-private device numbers, as Linux overlayfs does. Synthetic files keep sequential inode numbers on the filesystem's own device number, so they cannot collide with host files. getdents(2) no longer stats entries, neither on directfs nor in the gofer process. Across checkpoint/restore, inode numbers follow the host files, and the device number saved for a host device is reused for the device on which restored files are found. Device and inode numbers are therefore stable across restore when the backing files are unchanged, for all files rather than only those with an open FD. Conversely, inode numbers of files with an open FD may change if the backing filesystem changed, as they already do for other files. --inode-numbers=virtual keeps the previous behavior. Fixes #6665 Fixes #10047 Fixes #16197 FUTURE_COPYBARA_INTEGRATE_REVIEW=#16469 from ayushr2:gofer-ino-passthrough 8ead67b PiperOrigin-RevId: 1009090814
copybara-service Bot
pushed a commit
that referenced
this pull request
Oct 28, 2026
The gofer client assigns every file an inode number from a map keyed by the file's host device and inode numbers. The map gains an entry for every file the sandbox has ever looked up or listed and is never pruned, so sentry memory grows with the number of files seen: about 100 B of RSS per file, or 100 MiB for the life of the sandbox after a find over 1M files. Workspaces on host tmpfs never reuse inode numbers, so long-running sandboxes grow without bound. The key also makes getdents(2) stat(2) every entry to learn its device number. Report host inode numbers as is instead, and map host device numbers to sandbox-private device numbers, as Linux overlayfs does. Synthetic files keep sequential inode numbers on the filesystem's own device number, so they cannot collide with host files. getdents(2) no longer stats entries, neither on directfs nor in the gofer process. Across checkpoint/restore, inode numbers follow the host files, and the device number saved for a host device is reused for the device on which restored files are found. Device and inode numbers are therefore stable across restore when the backing files are unchanged, for all files rather than only those with an open FD. Conversely, inode numbers of files with an open FD may change if the backing filesystem changed, as they already do for other files. --inode-numbers=virtual keeps the previous behavior. Fixes #6665 Fixes #10047 Fixes #16197 FUTURE_COPYBARA_INTEGRATE_REVIEW=#16469 from ayushr2:gofer-ino-passthrough 8ead67b PiperOrigin-RevId: 1009090814
copybara-service Bot
pushed a commit
that referenced
this pull request
Oct 29, 2026
The gofer client assigns every file an inode number from a map keyed by the file's host device and inode numbers. The map gains an entry for every file the sandbox has ever looked up or listed and is never pruned, so sentry memory grows with the number of files seen: about 100 B of RSS per file, or 100 MiB for the life of the sandbox after a find over 1M files. Workspaces on host tmpfs never reuse inode numbers, so long-running sandboxes grow without bound. The key also makes getdents(2) stat(2) every entry to learn its device number. Report host inode numbers as is instead, and map host device numbers to sandbox-private device numbers, as Linux overlayfs does. Synthetic files keep sequential inode numbers on the filesystem's own device number, so they cannot collide with host files. getdents(2) no longer stats entries, neither on directfs nor in the gofer process. Across checkpoint/restore, inode numbers follow the host files, and the device number saved for a host device is reused for the device on which restored files are found. Device and inode numbers are therefore stable across restore when the backing files are unchanged, for all files rather than only those with an open FD. Conversely, inode numbers of files with an open FD may change if the backing filesystem changed, as they already do for other files. --inode-numbers=virtual keeps the previous behavior. Fixes #6665 Fixes #10047 Fixes #16197 FUTURE_COPYBARA_INTEGRATE_REVIEW=#16469 from ayushr2:gofer-ino-passthrough 8ead67b PiperOrigin-RevId: 1009090814
This was referenced Nov 6, 2026
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.
The gofer client assigns every file an inode number from a map keyed by
the file's host device and inode numbers. The map gains an entry for every
file the sandbox has ever looked up or listed and is never pruned, so
sentry memory grows with the number of files seen: about 100 B of RSS per
file, or 100 MiB for the life of the sandbox after a find over 1M files.
Workspaces on host tmpfs never reuse inode numbers, so long-running
sandboxes grow without bound. The key also makes getdents(2) stat(2) every
entry to learn its device number.
Report host inode numbers as is instead, and map host device numbers to
sandbox-private device numbers, as Linux overlayfs does. Synthetic files
keep sequential inode numbers on the filesystem's own device number, so
they cannot collide with host files. getdents(2) no longer stats entries,
neither on directfs nor in the gofer process.
Across checkpoint/restore, inode numbers follow the host files, and the
device number saved for a host device is reused for the device on which
restored files are found. Device and inode numbers are therefore stable
across restore when the backing files are unchanged, for all files rather
than only those with an open FD. Conversely, inode numbers of files with an
open FD may change if the backing filesystem changed, as they already do for
other files.
--inode-numbers=virtual keeps the previous behavior.
Fixes #6665
Fixes #10047
Fixes #16197