Reintroduce lookup/forget calls as notifications

[albel727]

It would be nice to have lookup(&Path)/forget(&Path) methods getting called when an inode is looked up for the first time/is removed after it's forgotten for the last time. The methods are not intended to do or return anything that Fuse would rely on, like actual lookup. The default implementations would be empty and hence optimized out.

It is useful to keep track of what kernel actually needs at the moment. For a FS that I'm writing I have to associate some resources with some files and directories, and it would lend itself well to allocate/free these resources on actual demand.

[wfraser]

Sounds reasonable. Only question I have is whether lookup is really necessary, because if you have forget, you can just check in getattr if you have seen a request for that path before or not. But it's easy to add, and fuse provides both for a reason. :)

[albel727]

Checking in getattr will mean excess lookup in user's HashMap and/or excess write locking of an RwLock that wraps user's HashMap. I think it's better to avoid that and provide for separation of concerns with a distinct lookup notification.

In fact, I'm not sure there isn't some possible utility in notifying user not just on first lookup/last forget, but on every one of them. And so it might be prudent to also pass the increment and current ref count (e.g. before increment for lookup and after increment for forget, so that count == 0 condition would be true for the first/last ref special cases). And then lookup(p: Path, count: u64, increment: u64) won't conflate with getattr(Path, Option<FileHandle>) at all.

[albel727]

After looking more closely, it seems implementing lookup/forget notifications with actually useful semantics isn't exactly straightforward. I'll show you my take on it, if I manage to, otherwise consider me never having posted this feature request.

[albel727]

Path-based notifications aren't very useful, after all. User will have to track renames, and it's not even obvious what to do with paths on unlinks and shadowing renames. And exposing inodes isn't straightforward because lookup() notification with inode should ideally be delivered before calls to any other methods using said inode, but the current code doesn't allocate an inode until after a successful call to target.getattr()/other entry creation call. Unless inodes are preallocated and passed to all handlers, nothing makes sense.

I guess I'll just have to use rust-fuse directly. You may close this issue, unless you intend to implement something like what's described in #21.