Hi! I know this has been discussed several times in several places, and the recent(ish) addition of NOTIFY_RESEND is an important step towards being able to restart a user-space FUSE server. While looking at how to restart a server that uses the libfuse lowlevel API, I've created an RFC pull request [1] to understand whether adding support for this operation would be something acceptable in the project. The PR doesn't do anything sophisticated, it simply hacks into the opaque libfuse data structures so that a server could set some of the sessions' fields. So, a FUSE server simply has to save the /dev/fuse file descriptor and pass it to libfuse while recovering, after a restart or a crash. The mentioned NOTIFY_RESEND should be used so that no requests are lost, of course. And there are probably other data structures that user-space file systems will have to keep track as well, so that everything can be restored. (The parameters set in the INIT phase, for example.) But, from the discussion with Bernd in the PR, one of the things that would be good to have is for the kernel to send back to user-space the information about the inodes it already knows about. I have been playing with this idea with a patch that simply sends out LOOKUPs for each of these inodes. This could be done through a new NOTIFY_RESEND_INODES, or maybe it could be an extra operation added to the already existing NOTIFY_RESEND. Anyway, before spending any more time with this, I wanted to ask whether this is something that could be acceptable in the kernel, if people think a different approach should be followed, or if I'm simply trying to solve the wrong problem. Thanks in advance for any feedback on this. [1] https://github.com/libfuse/libfuse/pull/1219 Cheers, -- Luís
