<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 4, 2015 at 2:35 PM, Prashanth Pai <span dir="ltr">&lt;<a href="mailto:ppai@redhat.com" target="_blank">ppai@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
----- Original Message -----<br>
&gt; From: &quot;Raghavendra Gowdappa&quot; &lt;<a href="mailto:rgowdapp@redhat.com">rgowdapp@redhat.com</a>&gt;<br>
&gt; To: <a href="mailto:gluster-devel@gluster.org">gluster-devel@gluster.org</a><br>
&gt; Cc: <a href="mailto:gluster-users@gluster.org">gluster-users@gluster.org</a><br>
&gt; Sent: Friday, September 4, 2015 12:43:09 PM<br>
&gt; Subject: [Gluster-devel] [posix-compliance] unlink and access to file through open fd<br>
&gt;<br>
&gt; All,<br>
&gt;<br>
&gt; Posix allows access to file through open fds even if name associated with<br>
&gt; file is deleted. While this works for glusterfs for most of the cases, there<br>
&gt; are some corner cases where we fail.<br>
&gt;<br>
&gt; 1. Reboot of brick:<br>
&gt; ===================<br>
&gt;<br>
&gt; With the reboot of brick, fd is lost. unlink would&#39;ve deleted both gfid and<br>
&gt; path links to file and we would loose the file. As a solution, perhaps we<br>
&gt; should create an hardlink to the file (say in .glusterfs) which gets deleted<br>
&gt; only when last fd is closed?<br>
&gt;<br>
&gt; 2. Graph switch:<br>
&gt; =================<br>
&gt;<br>
&gt; The issue is captured in bz 1259995 [1]. Pasting the content from bz<br>
&gt; verbatim:<br>
&gt; Consider following sequence of operations:<br>
&gt; 1. fd = open (&quot;/mnt/glusterfs/file&quot;);<br>
&gt; 2. unlink (&quot;/mnt/glusterfs/file&quot;);<br>
&gt; 3. Do a graph-switch, lets say by adding a new brick to volume.<br>
&gt; 4. migration of fd to new graph fails. This is because as part of migration<br>
&gt; we do a lookup and open. But, lookup fails as file is already deleted and<br>
&gt; hence migration fails and fd is marked bad.<br>
&gt;<br>
&gt; In fact this test case is already present in our regression tests, though the<br>
&gt; test checks whether the fd is just marked as bad. But the expectation of<br>
&gt; filing this bug is that migration should succeed. This is possible since<br>
&gt; there is an fd opened on brick through old-graph and hence can be duped<br>
&gt; using dup syscall.<br>
&gt;<br>
&gt; Of course the solution outlined here doesn&#39;t cover the case where file is not<br>
&gt; present on brick at all. For eg., a new brick was added to replica set and<br>
&gt; that new brick doesn&#39;t contain the file. Now, since the file is deleted, how<br>
&gt; do replica heals that file to another brick etc.<br>
&gt;<br>
&gt; But atleast this can be solved for those cases where file was present on a<br>
&gt; brick and fd was already opened.<br>
&gt;<br>
&gt; 3. Open-behind and unlink from a different client:<br>
&gt; ==================================================<br>
&gt;<br>
&gt; While open-behind handles unlink from the same client (through which open was<br>
&gt; performed), if unlink and open are done from two different clients, file is<br>
&gt; lost. I cannot think of any good solution for this.<br>
<br>
</div></div>We *may* have hit this once earlier when we had multiple instances of object-expirer daemon deleting huge number of objects (files).<br>
This was only observed at scale - deleting a million objects. Our user-space application flow was roughly as follows:<br>
<br>
fd = open(...)<br>
s = stat(fd)<br>
fgetxattr(fd, ....)<br>
<br>
In our case, open() and stat() succeeded but fgetxattr() failed with ENOENT (many times with ESTALE too) probably because some other client<br>
has done an unlink() on the file name already. Is this behavior normal ?<br></blockquote><div><br></div><div>Its possible (may not be normal, since we are being non-posix complaint here :)).<br>1. Open might&#39;ve been serviced by open-behind (faking it).<br>2. fstat might&#39;ve been served from md-cache (If it had hit open-behind, it would&#39;ve done an open before fstat is completed).<br></div><div>3. fgetxattr, if it hits open-behind and file is already deleted from some other client, fgetxattr will fail with ESTALE (not ENOENT, since open is done on gfid and if gfid cannot be looked-up, server-resolver sends out ESTALE).<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
@Thiago: Remember this one?<br>
<a href="http://paste.openstack.org/show/357414/" rel="noreferrer" target="_blank">http://paste.openstack.org/show/357414/</a><br>
<a href="https://gist.github.com/thiagodasilva/491e405a3385f0e85cc9" rel="noreferrer" target="_blank">https://gist.github.com/thiagodasilva/491e405a3385f0e85cc9</a><br>
<div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt; I wanted to know whether these problems are real enough to channel our<br>
&gt; efforts to fix these issues. Comments are welcome in terms of solutions or<br>
&gt; other possible scenarios which can lead to this issue.<br>
&gt;<br>
&gt; [1] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1259995" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1259995</a><br>
&gt;<br>
&gt; regards,<br>
&gt; Raghavendra.<br>
&gt; _______________________________________________<br>
&gt; Gluster-devel mailing list<br>
&gt; <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
&gt; <a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
&gt;<br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Raghavendra G<br></div>
</div></div>