>
So ls -i should show they all share the same inode number?It would, yes. Another useful tool here is du which by default will screen out files with duplicate inode numbers. So for an example where I have two 100M files each with multiple hard links:
me@swann:/tmp/tmp$ ls -lhi
total 701M
180277 -rw-r--r-- 3 me us 100M Aug 17 13:44 zero.file
180278 -rw-r--r-- 4 me us 100M Aug 17 13:45 zero.file.2
180278 -rw-r--r-- 4 me us 100M Aug 17 13:45 zero.file.2.link1
180278 -rw-r--r-- 4 me us 100M Aug 17 13:45 zero.file.2.link2
180278 -rw-r--r-- 4 me us 100M Aug 17 13:45 zero.file.2.link3
180277 -rw-r--r-- 3 me us 100M Aug 17 13:44 zero.file.link
180277 -rw-r--r-- 3 me us 100M Aug 17 13:44 zero.file.link2
me@swann:/tmp/tmp$ du -shc *
101M zero.file
101M zero.file.2
201M total
du does this duplicate ignorance trick across whole trees so the links do not have to be in the same directory, and you can have it scan a whole tree and it will show how much space it really taken, not how much is nominally taken. Like so:
me@swann:/tmp/tmp$ cd ..
me@swann:/tmp$ du -shc tmp
201M tmp
201M total
The reason I'm getting 101Mb instead of 100Mb (and 701Mb in total in ls) is that it is counting each link as taking a small amount of space, then "100MByte-plus-a-bit" is being rounded up to 101Mb (and 700-and-a-fraction rounds up to 701).
Also the number in the 3rd column of the ls output above is the number of links to the object, which can be helpful in understanding this sort of situation too.