ikosa Posted September 5, 2019 Share Posted September 5, 2019 root@Tower:/mnt/user/No_move# mkdir test root@Tower:/mnt/user/No_move# cd test root@Tower:/mnt/user/No_move/test# touch a root@Tower:/mnt/user/No_move/test# ln a b root@Tower:/mnt/user/No_move/test# ls -i 7288342 a 7288343 b Why in unraid hardlinked files does not share the same inode? I'm not a linux expert but i guess this means they are not hardlinks am i right? But when you check second column in ls -l seems like they are linked root@Tower:/mnt/user/No_move/test# ls -l total 0 -rw-rw-rw- 2 root root 0 Sep 5 14:34 a -rw-rw-rw- 2 root root 0 Sep 5 14:34 b When i make the same test in a docker container they share the same inode: root@66f7cacf879c:/root/test# touch a root@66f7cacf879c:/root/test# ln a b root@66f7cacf879c:/root/test# ls -i 8846 a 8846 b My real purpose is to find a files hardlinked copy or check its existance, but i cant do that because of the changed inode. Quote Link to comment
testdasi Posted September 5, 2019 Share Posted September 5, 2019 Hard links can's span physical volume. Potentially you have a in 1 disk and b in another disk. Quote Link to comment
ikosa Posted September 5, 2019 Author Share Posted September 5, 2019 2 hours ago, testdasi said: Hard links can's span physical volume. Potentially you have a in 1 disk and b in another disk. Thanks for your help. At first it make sense but arter i remember that the test i send at the above post was in the cache disk and cache only share. So i check again but now I am confused :s more than before with the result below: Quote root@Tower:/mnt/cache/No_move/test# ls -i /mnt/user/No_move/test 7288342 a 7288343 b root@Tower:/mnt/cache/No_move/test# ls -i /mnt/cache/No_move/test 2690930 a 2690930 b Quote Link to comment
testdasi Posted September 5, 2019 Share Posted September 5, 2019 13 minutes ago, ikosa said: So i check again but now I am confused :s more than before with the result below: That may be due to write being cache in RAM first. Quote Link to comment
itimpi Posted September 5, 2019 Share Posted September 5, 2019 (edited) 37 minutes ago, ikosa said: Thanks for your help. At first it make sense but arter i remember that the test i send at the above post was in the cache disk and cache only share. So i check again but now I am confused :s more than before with the result below: I suspect this is due to the fact that the first command is a reference to the physical drive while the second is going through the Fuse file system that is used to implement User Shares. I suspect that is also the underlying cause to the "User Share Bug" bug where the system does not recognise that both paths refer to the same file. Edited September 5, 2019 by itimpi Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.