gocryptfs on mergerfs: backing file inode number crosses reserved space

[Suika]

I'm currently using mergerfs to aggregate a few HDDs into a single directory and apply gocryptfs in reverse mode ontop of it to create a backup.

@trapexit had made a change to his inode algorithm in https://github.com/trapexit/mergerfs/commit/a646fe016dbd42abf9166ea47a473ca1177308dd which triggered the error in gocryptfs.
GetAttr "": backing file inode number 14920808378658256559 crosses reserved space, max=1000000000000000000. Returning EOVERFLOW.

I can circumvent the problem of the inodes, by removing the use_ino from mergerfs and using the fuse inodes, but the question is why it's done that way and why there is a limit.
It's a bit problematic for me, since I don't know to whom to report the problem.

[trapexit]

mergerfs is using the full 64bits of the inode (which AFAIK is entirely legit and not unique). I could add as special inode calculation mode that MODs the value by 10^19 but I imagine it's a matter of time till some other filesystem runs into this issue.

I understand the desire to reserve values for your own use but perhaps you could use the fact that filesystems don't need to have unique values. Or do you use public inode values internally for something?

[rfjakob]

I'd say the problem is with gocryptfs. I don't think mergerfs does anything wrong, just unusual. I'll see if there is way to fix it.

[trumblejoe]

@trapexit Hard linking would be the reason. Which programs like radarr and sonarr use.