> The file's inode (ie, 'stat->st_ino') is the one you see with ls -i (or
> 'stat') command. This can be different, and in glusterfs, this will be a
> value returned from backend filesystem (in master branch it will be
> lower 8bytes of gfid value).
Right. I fixed many confusions between nodeid and ino, but now I tend to
get an unreliable behavior from READDIR. Sometime the ino fits the value
I get through LOOKUP, sometimes it does not.
For instance, a directrories' correct ino (as reported by LOOKUP) is
264083456, but sometime READDIR gives me 383731716
On the backends the trusted.gfid attributes are correct and coherent:
20 95 82 15 fe aa 46 48 ac de 5f 3e 8d a7 76 e5
But none of the value above (16 df 48 04 and 0f bd 98 00) match the 8
lower bytes of gfid. This is 3.2.3
This is because in 3.2.3, the inode number was given directly from backend (and gets transformed at cluster translators depending on number of subvolumes). Only last week the constant inode number related patch got into 3.2.x branch codebase. (On master, it had gone in almost a month or two back).
Regards,
Amar