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.
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).
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.
Thanks
On Mon, Jan 26, 2015, 02:21 Sebastien Cote <sebas642 at yahoo.ca> wrote:
> Hi,
>
>
> 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:
>
> cluster.extra-hash-regex: "(.*)\\.tmp"
>
>
>
> 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 ?
>
> Thank you,
>
> Sebastien
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.gluster.org/pipermail/gluster-users/attachments/20150126/59b4f624/attachment.html>