Hardlinks not having the same inode number

[marktitorenkov]

I don't think this is an issue with the software but rather something I have misconfigured so not raising an issue.

What could be the reason for my hardlinked files not having the same inode numbers?

This is my config

/mnt/files1:/mnt/files2  /mnt/merge  fuse.mergerfs fsname=merge-1-2,allow_other,cache.files=partial,dropcacheonclose=true,category.action=epall,category.create=epff,category.search=ff,func.getattr=newest,ignorepponrename=true 0 0

Both /mnt/files1 and /mnt/files2 are zfs datasets.

mergerfs version: 2.33.5

If I have let's say two files in /mnt/files1/test that are hardlinks if i do

ls /mnt/files1/test

they have the same inode numbers

but if I do

ls /mnt/merge/test

they are different.

Any suggestions?

[trapexit]

You appear to be comparing inside and outside mergerfs mount. You should be comparing within the same mount. inodes are only unique within a filesystem. They can be the same across different filesystems. mergerfs could, but doesn't, just return the inode because that isn't unique enough given it is combining multiple filesystems. It has to create it's own and that is defined by the inodecalc option.

[marktitorenkov]

I am not saying that I expect the same values inside and outside. I expect two hardlinked files to have the same value between eachother. For example:

root@docker:/# ls -li /mnt/files1/test
total 1
37793 -rw-r--r-- 2 root root 0 Dec 20 18:11 test1
37793 -rw-r--r-- 2 root root 0 Dec 20 18:11 test2
root@docker:/# ls -li /mnt/merge/test
total 1
61344 -rw-r--r-- 2 root root 0 Dec 20 18:11 test1
61345 -rw-r--r-- 2 root root 0 Dec 20 18:11 test2

Why 61344 != 61345?

[trapexit]

OK, that wasn't what you presented originally. Regardless, it will if you have it setup correctly. You are also using a very old release. Till you upgrade I can't really comment further.

[marktitorenkov]

Thank you. I will upgrade to latest and retest.

[marktitorenkov]

Indeed. Simply upgrading to latest from github fixed the issue.

root@docker:~# ls -li /mnt/merge/test
total 1
908487488017825639 -rw-r--r-- 2 root root 0 Dec 20 18:11 test1
908487488017825639 -rw-r--r-- 2 root root 0 Dec 20 18:11 test2

I was using the latest from apt. Thank you.

[trapexit]

Yes, Debian packages are controlled by others. As I mention in the docs, even if I was maintaining it, it would almost always be out of date because non-testing Debian releases are always going to be out of date. That's the point of snapshot based releases. But as a maintainer I can't do anything about such a situation so I have to ask people to just upgrade first.