<div dir="ltr"><div><font face="monospace, monospace">Gluster uses changelogs to perform geo-replication. The changelogs record syscalls which are forwarded from the master cluster and played on slave cluster to provide the geo-replication feature.<br></font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">If two hard-links (h1 and h2) point to the same inode and a Python statement of os.rename(h1, h2) is executed, then no syscall gets logged to the changelog i.e. the syscall never reaches Gluster.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Is this behavior of renaming hard-links pointing to same inode guaranteed to NOT reach the file-system specific code?</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">I&#39;m repeating myself, but I think an example would help me explain much better:</font></div><div><font face="monospace, monospace">Consider the following sequence of syscalls:</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">CREATE f1           /* create file f1 */</font></div><div><font face="monospace, monospace">LINK   f1   h1      /* create hard-link h1 pointing to f1 */</font></div><div><font face="monospace, monospace">RENAME h1   h2      /* rename hard-link h1 to h2 */</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">All of the above goes well and we have f1 and h2 existing on the master and slave clusters.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">However, if geo-replication is stopped and restarted, then due to clock synchronization issues between nodes, the last changelog is replayed on the slave cluster. This replay causes problems during hard-link renames. So, the previously defined set of syscalls are replayed on the slave:</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">CREATE f1           /* ignored by Gluster due to same gfid exists */</font></div><div><font face="monospace, monospace">LINK   f1   h1      /* h1 created since it does not exist */</font></div><div><font face="monospace, monospace">RENAME h1   h2      /* silently ignored since it never reaches</font></div><div><font face="monospace, monospace">                     * Gluster since h1 and h2 point to the same inode</font></div><div><font face="monospace, monospace">                     */</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">So, at the slave cluster, we now have f1, h1 and h2.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">The issue now is, how to do away with the extra link h1 getting accumulated on the Gluster file-system. Ideally it shouldn&#39;t exist after changelogs are replayed.</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">Can Gluster assume that if the operands to a RENAME syscall point to the same inode, then file-system specific code to handle the rename syscall will never be invoked?</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">--</font></div><div><font face="monospace, monospace">Milind</font></div><div><br></div></div>