<br><br><div class="gmail_quote">On Mon, Feb 11, 2013 at 7:53 PM, Vijay Bellur <span dir="ltr"><<a href="mailto:vbellur@redhat.com" target="_blank">vbellur@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 02/12/2013 07:51 AM, Anand Avati wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<br>
On Mon, Feb 11, 2013 at 4:15 AM, Raghavendra Bhat <<a href="mailto:rabhat@redhat.com" target="_blank">rabhat@redhat.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:rabhat@redhat.com" target="_blank">rabhat@redhat.com</a>>> wrote:<br>
<br>
<br>
Hi,<br>
<br>
I have found out this behavior when open-behind is enabled.<br>
<br>
Suppose 2 fuse clients are mounted. Create a file with some data.<br>
open the file, sleep for some time, (while sleeping remove the file<br>
opened from other client), read from the opened fd. Actually since<br>
the file open was successful and fd is there, read operation should<br>
be successful. But with open-behind even though open is successful,<br>
read is failing and getting EUCLEAN (structure needs cleaning).<br>
<br>
When open-behind is turned off, then even though the file is deleted<br>
from other mount point after being opened, the process is able to<br>
read the file.<br>
<br>
<br>
This is not an issue introduced with the open-behind refactor. This<br>
behavior has always existed even in the previous quick-read xlator.<br>
<br>
</div></div></blockquote>
<br>
This issue needs to be addressed. Raghu - can you please open a bug for this?<br></blockquote><div><br></div><div>This is a tricky issue. We could minimize the probability with turning off lazy-open. But this behavior has always existed since 3.2 and 3.3 and not new with open-behind. Does this need an urgent fix for some reason?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Around the topic of open-behind, we need to fix the following for 3.4:<br>
<br>
a) Do not allow open-behind to resume dependent fops if the open() fails.<br></blockquote><div><br></div><div>Working on it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
b) Ensure that the cluster can handle open-behind being enabled by default in the client volume file. Due to this default enabling, we will break compatibility with 3.3 clients whenever new volume files are generated. A 3.3.x client trying to mount a volume with open-behind enabled will exit since it cannot understand open-behind in the volume file.</blockquote>
<div><br></div><div>This looks like a shortcoming in volgen as it seems to ignore the op-version fields for the options at the time of volfile generation (and only enforces during "gluster volume set").</div><div>
<br></div><div>Another option could be to introduce dynamic loading of optional xlators in a graph during init() and have the new quick-read load open-behind below it in runtime (without making an entry for open-behind in the volfile) -- as though quick-read/open-behind is a "set", specified only as "quick-read" in volfile syntax.</div>
<div><br></div><div>Avati</div></div>