[concerned_ctzn]

I'm not sure I understand you point, if an inode gets removed, then GETATTR or LOOKUP would fail as it should unless you're talking about open files. In the latter case the inode will get removed when the last open handle to the file is closed

[EdSchouten]

Sure, LOOKUP would obviously fail, as the object is no longer present in the file system under any name. GETATTR is a different story. Consider this sequence of operations:

    $ mkdir foo
    $ cd foo
    $ rmdir ../foo
    $ stat .                                                                                    
    16777221 401089477 drwxr-xr-x 2 ed staff 0 64 "Sep  6 06:41:05 2022" "Sep  6 06:41:05 2022" "Sep  6 06:41:05 2022" "Sep  6 06:41:05 2022" 4096 0 0 .

Notice how we removed a directory, and were still able to obtain its attributes afterwards using GETATTR. In fact, I can even go ahead and modify some of its attributes using SETATTR:

    $ touch .
    $ stat .
    16777221 401089477 drwxr-xr-x 2 ed staff 0 64 "Sep  6 06:45:34 2022" "Sep  6 06:45:34 2022" "Sep  6 06:45:34 2022" "Sep  6 06:41:05 2022" 4096 0 0 .

So that's what FORGET is for. It allows the kernel to hold on to inodes, even if they have been unlinked from the underlying file system, regardless of whether they are opened or not.

I think it's important to realise that a FUSE nodeid _does not_ represent an identifier of an inode in the file system. Instead, they are identifiers of the inode in the kernel's inode cache. Every time the object is returned by LOOKUP, MKDIR, MKNOD, LINK, SYMLINK or CREATE, should their reference count be increased. FORGET is called to decrease it again.