lisafs: move implementation to connections#13158
Closed
shayonj wants to merge 1 commit into
Closed
Conversation
ayushr2
reviewed
May 12, 2026
shayonj
force-pushed
the
s/lisafs-per-connection-opts
branch
from
9731246 to
24f3a12
Compare
shayonj
changed the title
ayushr2
reviewed
May 13, 2026
ayushr2
reviewed
May 13, 2026
shayonj
force-pushed
the
s/lisafs-per-connection-opts
branch
from
24f3a12 to
e6e41a0
Compare
ayushr2
reviewed
May 13, 2026
shayonj
force-pushed
the
s/lisafs-per-connection-opts
branch
from
e6e41a0 to
d868279
Compare
ayushr2
reviewed
May 13, 2026
Collaborator
ayushr2
left a comment
ayushr2
left a comment
There was a problem hiding this comment.
LGTM. Could you resolve merge conflict so I can pull it and fix it internally?
shayonj
force-pushed
the
s/lisafs-per-connection-opts
branch
2 times, most recently
from
9547dcc to
7744544
Compare
ayushr2
approved these changes
May 14, 2026
EtiennePerot
requested changes
May 14, 2026
Collaborator
EtiennePerot
left a comment
EtiennePerot
left a comment
There was a problem hiding this comment.
Please use any over interface{} throughout this PR
Move mount behavior and advertised LisaFS protocol configuration from the server implementation to a per-connection implementation. Server keeps only shared coordination state plus an opaque implementation value for handlers that need server-wide state, while each Connection reads its supported messages from ConnectionImpl and caches hot-path configuration such as max message size and options at startup. Rename ServerOpts to ConnectionOpts and expose it through ConnectionImpl so backend-specific semantics are selected together with the connection implementation. Remove unused fsgofer Config fields that were not server-wide.
shayonj
force-pushed
the
s/lisafs-per-connection-opts
branch
from
7744544 to
ead4588
Compare
Contributor
Author
|
ah! old habits :). Updated! |
copybara-service Bot
pushed a commit
that referenced
this pull request
May 14, 2026
The lisafs wire protocol already encodes the supported message list and the max message size per-mount on MountResp, but the server-side implementation reads both off a server-wide ServerImpl and reads ServerOpts off Server, so a custom implementation that needs to advertise different MIDs or run with different "OnDeleted" semantics has to bring its own lisafs.Server. That multi-Server shape carries its own renameMu, filesystem tree, and per-node opsMu instead of sharing them across mounts. This moves Mount, SupportedMessages, MaxMessageSize, and the former ServerOpts behind a per-Connection ConnectionImpl. Server keeps the shared renameMu, filesystem tree, connection lifecycle, and an opaque implementation value for existing fsgofer config access, while each Connection reads its supported MIDs from its ConnectionImpl and caches hot-path configuration such as max message size and ConnectionOpts at startup. Stock fsgofer behavior is unchanged because LisafsServer remains the server-wide config carrier and hands out a stock connection implementation. This is a precursor to a follow-up rework of #12950 that drops the multi-Server fan-out and lets LisafsServer choose a per-mount ConnectionImpl that returns the backend ControlFDImpl, all inside the single shared lisafs.Server. FUTURE_COPYBARA_INTEGRATE_REVIEW=#13158 from shayonj:s/lisafs-per-connection-opts ead4588 PiperOrigin-RevId: 915155303
copybara-service Bot
pushed a commit
that referenced
this pull request
May 14, 2026
The lisafs wire protocol already encodes the supported message list and the max message size per-mount on MountResp, but the server-side implementation reads both off a server-wide ServerImpl and reads ServerOpts off Server, so a custom implementation that needs to advertise different MIDs or run with different "OnDeleted" semantics has to bring its own lisafs.Server. That multi-Server shape carries its own renameMu, filesystem tree, and per-node opsMu instead of sharing them across mounts. This moves Mount, SupportedMessages, MaxMessageSize, and the former ServerOpts behind a per-Connection ConnectionImpl. Server keeps the shared renameMu, filesystem tree, connection lifecycle, and an opaque implementation value for existing fsgofer config access, while each Connection reads its supported MIDs from its ConnectionImpl and caches hot-path configuration such as max message size and ConnectionOpts at startup. Stock fsgofer behavior is unchanged because LisafsServer remains the server-wide config carrier and hands out a stock connection implementation. This is a precursor to a follow-up rework of #12950 that drops the multi-Server fan-out and lets LisafsServer choose a per-mount ConnectionImpl that returns the backend ControlFDImpl, all inside the single shared lisafs.Server. FUTURE_COPYBARA_INTEGRATE_REVIEW=#13158 from shayonj:s/lisafs-per-connection-opts ead4588 PiperOrigin-RevId: 915155303
copybara-service Bot
pushed a commit
that referenced
this pull request
May 14, 2026
The lisafs wire protocol already encodes the supported message list and the max message size per-mount on MountResp, but the server-side implementation reads both off a server-wide ServerImpl and reads ServerOpts off Server, so a custom implementation that needs to advertise different MIDs or run with different "OnDeleted" semantics has to bring its own lisafs.Server. That multi-Server shape carries its own renameMu, filesystem tree, and per-node opsMu instead of sharing them across mounts. This moves Mount, SupportedMessages, MaxMessageSize, and the former ServerOpts behind a per-Connection ConnectionImpl. Server keeps the shared renameMu, filesystem tree, connection lifecycle, and an opaque implementation value for existing fsgofer config access, while each Connection reads its supported MIDs from its ConnectionImpl and caches hot-path configuration such as max message size and ConnectionOpts at startup. Stock fsgofer behavior is unchanged because LisafsServer remains the server-wide config carrier and hands out a stock connection implementation. This is a precursor to a follow-up rework of #12950 that drops the multi-Server fan-out and lets LisafsServer choose a per-mount ConnectionImpl that returns the backend ControlFDImpl, all inside the single shared lisafs.Server. FUTURE_COPYBARA_INTEGRATE_REVIEW=#13158 from shayonj:s/lisafs-per-connection-opts ead4588 PiperOrigin-RevId: 915155303
Collaborator
|
@shayonj I did some more surgery, please take a look at #13180 I essentially got rid of the entire ServerImpl thing. Having both ConnectionImpl and ServerImpl was redundant and complex. All the ServerImpl was doing was holding server-wide configuration. The ConnectionImpl can do that too: |
Contributor
Author
|
Thank you for the thorough review as usual. I will take it there and close this. Let me know if you'd like to keep this open and happy to as well. |
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
3 participants
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 lisafs wire protocol already encodes the supported message list and the max message size per-mount on MountResp, but the server-side implementation reads both off a server-wide ServerImpl and reads ServerOpts off Server, so a custom implementation that needs to advertise different MIDs or run with different "OnDeleted" semantics has to bring its own lisafs.Server. That multi-Server shape carries its own renameMu, filesystem tree, and per-node opsMu instead of sharing them across mounts.
This moves Mount, SupportedMessages, MaxMessageSize, and the former ServerOpts behind a per-Connection ConnectionImpl. Server keeps the shared renameMu, filesystem tree, connection lifecycle, and an opaque implementation value for existing fsgofer config access, while each Connection reads its supported MIDs from its ConnectionImpl and caches hot-path configuration such as max message size and ConnectionOpts at startup. Stock fsgofer behavior is unchanged because LisafsServer remains the server-wide config carrier and hands out a stock connection implementation.
This is a precursor to a follow-up rework of #12950 that drops the multi-Server fan-out and lets LisafsServer choose a per-mount ConnectionImpl that returns the backend ControlFDImpl, all inside the single shared lisafs.Server.