-
Notifications
You must be signed in to change notification settings - Fork 162
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
Add build cfg for FUSE mounting implementation to fuser #1106
Open
dannycjones
wants to merge
10
commits into
awslabs:fuser/fork
Choose a base branch
from
dannycjones:fuser/add-cfg-for-mount-impl
base: fuser/fork
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Add build cfg for FUSE mounting implementation to fuser #1106
dannycjones
wants to merge
10
commits into
awslabs:fuser/fork
from
dannycjones:fuser/add-cfg-for-mount-impl
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
Currently the Filesystem trait forces only a single request dispatch loop, with the idea that a filesystem that wants to be concurrent can just spawn its own threads and dispatch operations on them itself. This works, but it's bad for performance, because it forces every request to bounce across threads. Instead, let's make the Filesystem trait use interior mutability. This allows us to spawn multiple dispatch threads that each block on the FUSE device, read a request, and immediately dispatch it without the bounce. Unfortunately there's not a good way for a trait to be variant in mutability, so this is a breaking API change. We'll need to think more carefully about how to upstream this change. Signed-off-by: James Bornholt <[email protected]>
Add `is_forget()` method to `Request`. Signed-off-by: Alessandro Passaro <[email protected]>
Introduce `Session::run_with_callbacks()` to notify callers before and after kernel messages are dispatched. Signed-off-by: Alessandro Passaro <[email protected]>
## Description of change fuser v0.15.0 added support for creating sessions from FUSE fd. I'm working on a PR to add this support to Mountpoint. We still need to open the FUSE device and call `mount` syscall in order to test this new behavior, and all this logic is already exists with `mnt::Mount`. We could just copy the logic from `mnt::Mount` - but since we already have this fork, making this change seemed fine to me. Maybe we can also consider upstreaming it. ## Does this change impact existing behavior? No ## Does this change need a changelog entry in any of the crates? No --- 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)](https://developercertificate.org/). Signed-off-by: Burak Varli <[email protected]>
Signed-off-by: Daniel Carl Jones <[email protected]>
Signed-off-by: Daniel Carl Jones <[email protected]>
passaro
approved these changes
Nov 6, 2024
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice.
## Description of change Our fuser fork emits a lot of warnings during builds, impacting our pull requests. This change addresses missing documentation on one struct in fuser (which was introduced by our change in awslabs#1098). This change is a good candidate to be contributed to upstream. Once contributed, this commit can be removed. Relevant issues: N/A ## Does this change impact existing behavior? No. --- 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)](https://developercertificate.org/). --------- Signed-off-by: Daniel Carl Jones <[email protected]>
Signed-off-by: Daniel Carl Jones <[email protected]>
Addressed some changes which would be needed if upstreaming. |
dannycjones
force-pushed
the
fuser/fork
branch
2 times, most recently
from
November 12, 2024 17:15
bd3bdc9
to
daad567
Compare
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
Our fuser fork emits a lot of warnings during builds, impacting our pull requests. This change addresses the use of undeclared feature flags.
In this change, we replace the feature flags with new
cfg
field which is just for the fuser mount implementation, having values ofpure-rust
,libfuse2
, andlibfuse3
. Ideally, Fuser may be able to just determine which libfuse value is available at runtime and not need compile-time flags to distinguish betweenlibfuse2
andlibfuse3
. For now though, this addresses the immediate issue.This change is a good candidate to be contributed to upstream (cberner/fuser#311). Once contributed, this commit can be removed.
Relevant issues: N/A
Does this change impact existing behavior?
There should be no change to existing behavior. (We should ensure CI passes for this change.)
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).