Consider providing inode numbers or inode-associated user data to handlers

[albel727]

It is often necessary to associate some data with files. Currently, data association is only possible via some HashMap<PathBuf, UserData> field in FS struct. Long strings with long common prefixes, which pathnames usually are, aren't the best thing for quick lookups, though. I see the following two alternatives (which would be most useful provided existence of lookup/forget methods from #20, which then also should accept some of the parameters described below).

For one, handlers could receive inode numbers for parameters in addition to Paths. Then user can at least employ HashMap<Inode, UserData>, which would have faster lookup. If user further relies on the current inode reuse behavior of fuse-mt, they might even go for Vec<UserData> and index into it with inode numbers, and it also would be more parallelizable than HashMap.

For another alternative, user may be spared the effort to keep inode-associated data altogether. InodeTable might be made generic on and keep inside a user-defined value for every inode, which it would provide to handlers for use/modification. Current InodeTable would be equivalent to InodeTable<()>, which can be made the default with something like FuseMT<T, U=()> { inodes: InodeTable<U> }.

It would be most flexible, if those alternatives were combined, and instead of user data parameters, handlers were provided with inode numbers and direct access to InodeTable for lookup/modification of user data by inode number. Then user could freely access the data for all inodes, and not just for inode that a handler was called with.

In fact, if InodeTable were exposed to user, then it would also be possible to omit Path parameters to handlers altogether and provide user with just the inode numbers and facility to lookup paths by inode. It would cut some overhead for when user doesn't even need a Path to do some action. A fully-sugared backward-compatible interface with Path parameters probably could be provided on top of that.

[droundy]

This feature is also needed if you want it to be possible to implement a posix filesystem. Otherwise there is no way for the filesystem to determine which file is being read if a user opens a file, then unlinks it, then creates another file with the same name.