Atomicity of rename() has two aspects. One is the back end view (for crash consistency), of having an unambiguous single point in time when the rename is declared complete. Dht does quite a few tricks to make this atomicity work well in practice. The other is the effect on API, in particular the effect on open() of a file which is getting replaced by a rename of another file over it. The nature of fuse operations (i.e split into lookup() followed by open() on the result of lookup) makes it almost impossible to handle the case when lookup happens before the backend rename, and open() arrives on the file handle which is now gone (deleted due to replace) during rename.<br><br>For theoretical correctness, we would need fuse to forward the open-intent flag in lookup, so that Gluster can keep the file pre-open in anticipation of the imminent arrival of open() fop - guarding against getting replaced by a different file in the mean time. However the recent upstream kernel patchset of handling ESTALE with a retry, along with fixes in Gluster to be careful of returning ESTALE vs ENOENT minimize the window of race. This may be good enough for a lot of use cases (though still possible to hit the race if you are creating temp files and renaming them to the filename of interest in a tight loop).<br><br>Extending fuse with open-intent flag and its proper usage in Gluster is the foolproof fix, but I dont think anyone is working on this yet.<br><br>Thanks<br><br><div class="gmail_quote">On Mon, Jan 26, 2015, 02:21 Sebastien Cote <<a href="mailto:sebas642@yahoo.ca">sebas642@yahoo.ca</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
<br>
I was wondering if there was a way to make the rename operation atomic with Gluster 3.6. I have seen older posts on this list suggesting the use of the following configuration parameter:<br>
<br>
cluster.extra-hash-regex: "(.*)\\.tmp"<br>
<br>
<br>
<br>
I did not see comments on the success or failure of that method, or a proposition for an alternative. So is atomic rename a dead end, even with Gluster 3.6 ?<br>
<br>
Thank you,<br>
<br>
Sebastien<br>
______________________________<u></u>_________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-users" target="_blank">http://www.gluster.org/<u></u>mailman/listinfo/gluster-users</a><br>
</blockquote></div>