Hi @llaith & @khanhtranngoccva
You bothered mentioned issue resolved by this PR #63 : the fact that in heavy duty, inodes are removed from inode_mapper before all pending executions to that inode are made.
However that still puzzles me on why it happens. If this is a problem in easy_fuser code, an inevitable consequence of parralism operations, or the way that libfuse works. For now the problem were resolved by never removing inode to path mapping (memory leakage) and introducing punctual prune method #87 (could coexist with immediate pruning by the way, just two different modes).
Looking at a similar crate (fuse-mt), the inode is removed when lookup count go to zero (but fuse-mt parallelized only a subset of methods).
So if you have a reproductible way to demonstrate the bug (for example a python or bash script), it would help greatly !
Hi @llaith & @khanhtranngoccva
You bothered mentioned issue resolved by this PR #63 : the fact that in heavy duty, inodes are removed from inode_mapper before all pending executions to that inode are made.
However that still puzzles me on why it happens. If this is a problem in easy_fuser code, an inevitable consequence of parralism operations, or the way that libfuse works. For now the problem were resolved by never removing inode to path mapping (memory leakage) and introducing punctual prune method #87 (could coexist with immediate pruning by the way, just two different modes).
Looking at a similar crate (fuse-mt), the inode is removed when lookup count go to zero (but fuse-mt parallelized only a subset of methods).
So if you have a reproductible way to demonstrate the bug (for example a python or bash script), it would help greatly !