Is there a way to trigger `destroy()` in `FileSystem` trait on Linux after mounting?
KongzhangHao opened this issue · comments
After the filesystem is mounted on Linux with mount_with_unprivileged(), I'm trying to trigger the destroy() method in FileSystem trait to actually close the filesystem. I've been trying with fusermount -u /path/ and umount /path/, but both commands didn't trigger destroy(). I've also tried killing the fuse process, but it still didn't work. May I know if there is a way to trigger destroy()?
The documentation mentions that destroy() can only be triggered in fuseblk mode (which is not supported yet by fuse3), and the program may receive a forget(root_inode) signal instead during unmounting. However, the signal is actually never received in the experiments, and fuse3 doesn't not receive anything from its channel. Is there any way that the program can know umount is called?
in previous fuse3 use normal tokio file to communicate with kernel which is a blocking file, when unmount the fs fuse3 can know it.
now fuse3 use a non-blocking file to reduce internal spawn blocking, but the unmount event is miss
i am still finding the way to let fuse3 know the fs is unmount
Thank you very much!
in previous fuse3 use normal tokio file to communicate with kernel which is a blocking file, when unmount the fs fuse3 can know it. now fuse3 use a non-blocking file to reduce internal spawn blocking, but the unmount event is miss i am still finding the way to let fuse3 know the fs is unmount
I currently solve the issue by spawning an async task that listens to the kernel interrupt (e.g. SIGTERM), and calls destroy() /forget(root) when a corresponding kill signal is received. May I ask if I can make a pull request to merge it as a new feature?
in previous fuse3 use normal tokio file to communicate with kernel which is a blocking file, when unmount the fs fuse3 can know it. now fuse3 use a non-blocking file to reduce internal spawn blocking, but the unmount event is miss i am still finding the way to let fuse3 know the fs is unmount
I currently solve the issue by spawning an async task that listens to the kernel interrupt (e.g. SIGTERM), and calls
destroy()/forget(root)when a correspondingkillsignal is received. May I ask if I can make a pull request to merge it as a new feature?
i think you can add a new struct, such as NotifyDestroy, allow user call destroy outside the fuse connection, to fix this problem temporarily
that makes user decide how to trigger destroy, not only the signal