Bug 764774 (GLUSTER-3042)

so, to achieve this, consider getting the inode number from gfid itself, which is guaranteed to be uniq.

Let posix itself send the 'st_ino' calculated from 'gfid'. This will protect the inode number returning logic of glusterfs even in case of backend inode number reallocation in backend filesystems.

(In reply to comment #1)
> As an extension to this, I'd like to propose that the GFID-based inode number
> be returned all the way up through AFR (which can return different values from
> different replicas) and DHT (which can return different values whenever bricks
> are added/removed because of the way dht_*itransform works).  Having inode
> numbers that are stable despite underlying configuration changes would be
> awesome.

http://patches.gluster.com/patch/7524/ does exactly that.

(In reply to comment #2) 
> http://patches.gluster.com/patch/7524/ does exactly that.

Most excellent.

PATCH: http://patches.gluster.com/patch/7524 in master (core: fill 'ia_ino' from 'ia_gfid' in 'storage/posix' to preserve same ino number)

now the inode number (st_ino) of the stat structure is derived from gfid, hence, we are _almost_ guaranteed to have unique inode in cluster without any 'itransform' or anything. Which will help in preserving inode numbers even after a scale-out or scale-down operation.

the inodes are found to be different from different clients,

on client1,
glusterfs#10.1.12.134:/dr3 on /mnt/fuse-test type fuse (rw,allow_other,default_permissions,max_read=131072)
[root@centos-qa-client-3 ~]# ls -li /mnt/fuse-test/
total 280
18446744053835159371 -rw-r--r-- 1 root root 1024 Jul 22 01:19 f.1
18446744055578181635 -rw-r--r-- 1 root root 1024 Jul 22 01:13 f.10
18446744058569784671 -rw-r--r-- 1 root root 1024 Jul 22 01:13 f.11
18446744054862085589 -rw-r--r-- 1 root root 1024 Jul 22 01:13 f.12
          3611390631 -rw-r--r-- 1 root root 1024 Jul 22 01:19 f.13


on client2,
[root@centos-qa-client-2 ~]# ls -li /mnt/quota_nfs
total 280
18446744070397152908 -rw-r--r-- 1 root root 1024 Jul 22 01:19 f.1
18446744070687656619 -rw-r--r-- 1 root root 1024 Jul 22 01:19 f.10
18446744071186257125 -rw-r--r-- 1 root root 1024 Jul 22 01:19 f.11
18446744070568307278 -rw-r--r-- 1 root root 1024 Jul 22 01:19 f.12
           601898438 -rw-r--r-- 1 root root 1024 Jul 22 01:19 f.13



even on client1,

re-mounting gave different values,
[root@centos-qa-client-3 ~]# umount /mnt/fuse-test
[root@centos-qa-client-3 ~]# mount -t glusterfs 10.1.12.134:/dr3 /mnt/fuse-test/
[root@centos-qa-client-3 ~]# ls -li /mnt/fuse-test/
total 280
18446744053835159368 -rw-r--r-- 1 root root 1024 Jul 22 01:13 f.1
18446744055578181638 -rw-r--r-- 1 root root 1024 Jul 22 01:19 f.10
18446744058569784674 -rw-r--r-- 1 root root 1024 Jul 22 01:19 f.11
18446744054862085592 -rw-r--r-- 1 root root 1024 Jul 22 01:19 f.12
          3611390628 -rw-r--r-- 1 root root 1024 Jul 22 01:13 f.13

for the above test, the master is sync'd to this point,

commit 37b4b7ccad5a479ed2ce96598e902a12fd457bd5
Author: Raghavendra Bhat <raghavendrabhat>
Date:   Wed Jul 20 12:21:12 2011 +0530

    debug/io-stats: allow log-level to be set to INFO
    
    Change-Id: Ieba6591b0641dcb7dad724c1d8199dc5e91b6bfd

Tried the tests to check if there are changes in inode number across re-mounts, different mounts etc. In all tests it was same. (Tried it in master branch).

with the latest sync to the repository , I am also not finding this issue, even after replace brick the inode number does not change.


But I don't how come the issue was seen earlier!

verified it

(In reply to comment #9)
> with the latest sync to the repository , I am also not finding this issue, even
> after replace brick the inode number does not change.
> 
> 
> But I don't how come the issue was seen earlier!

Can you not rollback to the old code snapshot and check if it actually was dude to the presence/absence of the stable inode number patch?

CHANGE: http://review.gluster.com/624 (take the least significant 64bit from gfid and assign it to 'ia_ino',) merged in release-3.2 by Vijay Bellur (vijay)

CHANGE: http://review.gluster.com/632 (as posix layer itself sends inode numbers based on gfid now) merged in release-3.2 by Vijay Bellur (vijay)