<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 26, 2013 at 3:37 PM, Amar Tumballi <span dir="ltr"><<a href="mailto:atumball@redhat.com" target="_blank">atumball@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
This is an extended discussion on patch <a href="http://review.gluster.org/4702" target="_blank">http://review.gluster.org/4702</a><br>
<br>
With this patch going in, a mount point can be made to access the files directly using the gfid of the files, and not just path.<br>
<br>
We are planning to use this along with Changelog [1] for enhanced geo-replication feature we are planning to develop. Now, the good thing is, with these combination we have many benefits, which primarily includes not crawling the system to find the changes done in last N minutes.<br>
<br>
But the challenge we have now is with the upgrading of the existing geo-replication setup to newer one, where we would need to keep the 'slave' volume's files to have the exact same GFID as that of 'master' volume. To achieve this, when we upgrade, we would need a *method* to change the GFID of the existing files in 'slave' volume on the fly.<br>
<br>
We have couple of options:<br>
<br>
1. delete the '.glusterfs/' directory from the slave volume and use the aux-gfid-path based mount to do the lookup (with proper GLUSTERFS_GFID env variable set), so it creates the gfid with new one.<br>
* needs a change in posix xlator to overwrite existing 'trusted.gfid' attribute too.<br></blockquote><div><br></div><div>This approach is inline with gfid healing we already have and requires very less code change within glusterfs (we might need a script to remove existing gfid xattrs and send a stat on each file with correct gfid from master). However the parallel use of mount point by other applications during the window of time (after gfid xattr deletion, before lookup with correct gfid copied from master) might result in a file having a different gfid from its counterpart in master. Hence, this approach does not bode well for rolling upgrades (upgrades without downtime).<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2. bring a setxattr() interface to change the gfid on the fly based on a virtual xattr.<br>
* needs extra check as the existing inode number (aka, gfid) suddenly changes, and we need to handle it gracefully.<br></blockquote><div><br></div><div>This approach is also simple, but requires relatively more code change within glusterfs (compared to 1). If we happen to change gfid of an already looked up inode, protocol/client fails revalidate (re-lookup) on that file with ESTALE and fuse-bridge sends a fresh lookup on that path. The effect of this would be we send a new nodeid to kernel as reply of revalidate. And kernel too will create a new inode replacing old inode for that file. Hence AFAIK this wouldn't cause any problem. This approach is also good since we change gfid atomically. Hence rolling upgrades are possible with this approach.<br>
<br></div><div>Given the advantages of approach 2, I would prefer it. Thanks to Csaba for his inputs.<br><br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Let me know if someone has better options, or can take a call on which is the better approach.<br>
<br>
Regards,<br>
Amar<br>
<br>
[1] - <a href="http://review.gluster.org/4766" target="_blank">http://review.gluster.org/4766</a><br>
<br>
______________________________<u></u>_________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@nongnu.org" target="_blank">Gluster-devel@nongnu.org</a><br>
<a href="https://lists.nongnu.org/mailman/listinfo/gluster-devel" target="_blank">https://lists.nongnu.org/<u></u>mailman/listinfo/gluster-devel</a><br>
</blockquote></div><br><br clear="all"></div><div class="gmail_extra">regards,<br></div><div class="gmail_extra">-- <br>Raghavendra G<br>
</div></div>