Suggestion for a new inodecalc method

[thrnz]

One weakness of using the underlying device id (st_dev) to generate inodes is that it isn't guaranteed to remain the same across reboots. In my case, ZFS datasets are sometimes assigned different st_dev values at boot, causing the inodes generated by mergerfs to occasionally change after restarts. I use backup software that uses a file's inode to handle hardlink backup/restore which is unable to do this with the current inodecalc methods as it gets confused when some of the generated inodes change across boots.

I've worked around this by using a new inodecalc method that generates inodes based on the file's base path + underlying inode. For instance, a file that mergerfs mounts at /mnt/merged/somepath/somefile.txt which is in reality located at /mnt/disk3/somepath/somefile.txt would generate an inode by hashing /mnt/disk3 + the underlying inode value. I've used this method (along with path-hash for directories) for the past year or so without noticing any unwanted side effects. There are limitations though, so it's not suitable as a default setting. For instance, if there are multiple device id's under a base path, different files may end up with the same generated inode. In my specific use-case though this isn't an issue and my backups/restores/everything else has run without noticeable problems.

I can link the changes that shows what I've been using if you're interested in checking them out. I'm relatively inexperienced with C++ - even moreso when I made these changes - so would not be surprised if I've broken something else unintentionally, but it'll at least give a general idea of what I was trying to achieve.

[trapexit]

Sure. Happy to add it. You're welcome to submit a pull request or point me to it and I can add it.

[thrnz]

This is what I've been using. I called the new method basepath-hash and also added a 32 bit variant. I also added basehybrid-hash which is similar to the existing hybrid-hash that instead uses path-hash for directories. They could probably have better names.

I'm not confident enough in my code to use it for a PR, so I'll let you choose what to re-use and what might need redoing.