Kernel notification support #140
Conversation
| @@ -95,6 +98,8 @@ type fileSystemServer struct { | |||
| } | |||
|
|
|||
| func (s *fileSystemServer) ServeOps(c *fuse.Connection) { | |||
| s.fs.SetConnection(c) | |||
There was a problem hiding this comment.
What’s this SetConnection call for? Is it needed? Can you add a comment to the source to explain?
There was a problem hiding this comment.
It's needed to have something to call Notify() on :)
There was a problem hiding this comment.
I don’t think SetConnection should be added to this interface.
If you want to store a connection field in your FS implementation, that’s fine.
Personally, I would just add a conn: conn, field to where I construct the &fuseFS{…}.
But if it doesn’t absolutely need to be in the interface (which I don’t think it does?), it should not be added.
There was a problem hiding this comment.
It should be exported to the user FS code somehow. How to do it?
I mean, the thing that implements interface FileSystem must be able to call SetConnection() or Notify() on something.
Currently we do
fsint := NewGoofysFuse(fs)
server := fuseutil.NewFileSystemServer(fsint)
fuseMfs, err := fuse.Mount(fs.flags.MountPoint, server, mountCfg)
I think there's an option to add Notify() method to the server - would it be ok? It will only work when ServeOps(connection) is active though
There was a problem hiding this comment.
Sorry, I still don’t quite understand.
Can you show me the code that uses this feature? Without an example implementation it’s hard to think this through.
There was a problem hiding this comment.
There was a problem hiding this comment.
Thanks for the example. Seeing how the code is used makes me think that we should not pursue the SetConnection approach. It seems unclean to expose the internal connection and thereby let users call methods in any order (e.g. Connection.Reply, which the doc comment explicitly mentions should not be called).
@jacobsa Would you have a suggestion regarding your preferred way to model this? I’m thinking it would be cleaner to collect kernel notifications and then send them on the connection from an internal function. Perhaps that could also help in preventing the deadlock that is mentioned in the doc comment?
vitalif
force-pushed
the
notifications
branch
from
a091e49
to
299578a
Compare
|
Hi, could you return to this PR and merge it? :-) I have more changes to submit :) |
This PR adds support for notifications from the FUSE server app to the kernel, including:
I tested these in https://github.com/yandex-cloud/geesefs and on Linux these seem to work just fine. Didn't check MacOS because I don't use it, but seems they're also supported there since osxfuse-3.7 https://github.com/osxfuse/osxfuse/releases/tag/osxfuse-3.7.0