lisafs: move implementation to connections#13180
Conversation
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: 915234536
There was a problem hiding this comment.
This is def cleaner, thank you for taking it on. I was staring to wonder about Server.impl and it'use other than carrying fsgofer config.
I guess if we are consolidating this path, I’m wondering whether the #12950 follow-up should route connection creation through a small per-mount factory/extension that returns both ConnectionImpl and ConnectionOpts. That seems to fit this API well because CreateConnection needs the implementation before Mount anyway, since MaxMessageSize is cached at connection boot
That also seems like it would compose well with the per-mount diretfs opt-out (13098). The factory can build the stock fsgofer impl with DonateMountPointFD disabled only for mounts that suppress directfs, while custom backends can return an impl that does not donate a host fs at all.
One possible behavioral thought I have is if Connection should cache/enforce SupportedMessages server-side too? The client respects the advertised list, but with mixed implementations on one shared server, making handleMsg reject non-advertised MIDs would make the per-connection protocol surface source of truth?
| // will fail with EROFS. | ||
| readonly bool | ||
| // opts is the cached value of impl.ConnectionOpts(). | ||
| opts ConnectionOpts |
There was a problem hiding this comment.
nit: opts is passed into CreateConnection now rather than read from impl.ConnectionOpts IIUC?
| // MaxMessageSize implements lisafs.MaxMessageSize. | ||
| func (s *testServer) MaxMessageSize() uint32 { | ||
| // ConnectionOpts implements lisafs.ConnectionImpl.ConnectionOpts. | ||
| func (s *testConnImpl) ConnectionOpts() lisafs.ConnectionOpts { |
There was a problem hiding this comment.
Looks like this method is stale now that ConnectionImpl no longer has ConnectionOpts
1 participant
lisafs: move implementation to connections
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