Repository navigation
Keep less memory per file a mount is asked about - #188
Merged
Merged
Conversation
Box the rarely set removed_from of each inode, keep only directories in the core's path-to-entry cache (files are one listing lookup further), share that cache's keys with the entries' own, shrink the inode table once the kernel forgets most of it, and cap a git mount's recent whole file reads at 64 MiB. A 200k-file walk goes from 147 MB to 89 MB with the same walk times. With files out of the path-entry cache, a recheck of a shrunk file changes only its listing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013jkdGETmgGUb8hcSEpppQK
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
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.
Requested by George · project thread
What changed
George's priority is keeping the mount's RAM as low as possible. A walk of a 200k-file folder (
findthenls -lR) made the mount process hold 147 MB, about 740 bytes per path. A heap profile at 20k files put 33% in the inode table, 24% in the core's path-to-entry cache, 22% in listings and 11% in path-to-inode. This PR trims the first two and caps one cache.workspace.rs): only directories are kept. Files far outnumber them, and a file is found in its directory's listing, one lookup more. The cache's keys share the entry's own key bytes when they're the same path, as in a folder.workspace.rs): with files out of that cache, rechecking a shrunk file (Never pad a file that shrank under a mount with zeros #186) changes only its listing, sopatch_listingloses its closure.fs.rs): the rarely setremoved_fromis boxed, and the table shrinks once the kernel has forgotten most of it (capacity over 4096, length under a quarter).fs.rs): recent whole-file reads are capped at 64 MiB instead of 256 MiB.Measured on Linux FUSE, release build, 200k files, mount process anonymous memory:
find+ls -lRWalk times are unchanged. What's freed goes back to the system on the musl release builds; glibc keeps it for reuse. The workspace forbids unsafe code, so the mount doesn't call
malloc_trim. macOS isn't measured yet.API changes
None.
Tests
cargo test --workspace --no-fail-fastpasses here, except the twosandfs shelltests that need bubblewrap, which isn't installed in this container.cargo clippy --workspace --all-targets -- -D warningsandcargo fmt --checkare clean.Generated by Claude Code