On 02/12/2013 11:48 AM, Anand Avati wrote:
On Mon, Feb 11, 2013 at 7:53 PM, Vijay Bellur <vbellur@xxxxxxxxxx
<mailto:vbellur@xxxxxxxxxx>> wrote:
On 02/12/2013 07:51 AM, Anand Avati wrote:
On Mon, Feb 11, 2013 at 4:15 AM, Raghavendra Bhat
<rabhat@xxxxxxxxxx <mailto:rabhat@xxxxxxxxxx>
<mailto:rabhat@xxxxxxxxxx <mailto:rabhat@xxxxxxxxxx>>> wrote:
Hi,
I have found out this behavior when open-behind is enabled.
Suppose 2 fuse clients are mounted. Create a file with some
data.
open the file, sleep for some time, (while sleeping remove
the file
opened from other client), read from the opened fd.
Actually since
the file open was successful and fd is there, read
operation should
be successful. But with open-behind even though open is
successful,
read is failing and getting EUCLEAN (structure needs cleaning).
When open-behind is turned off, then even though the file
is deleted
from other mount point after being opened, the process is
able to
read the file.
This is not an issue introduced with the open-behind refactor. This
behavior has always existed even in the previous quick-read xlator.
This issue needs to be addressed. Raghu - can you please open a bug
for this?
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?
No urgency, but this would be a good fix to have. We have also seen some
EUCLEAN errors in the past but have not been able to identify the root
cause of such errors.
We should either unconditionally disable lazy-open or make the lazy-open
behavior configurable and turn it off by default.
Around the topic of open-behind, we need to fix the following for 3.4:
a) Do not allow open-behind to resume dependent fops if the open()
fails.
Working on it.
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.
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").
Enhancing volgen to incorporate op-version does seem like a good idea.
Let us explore this path.
-Vijay
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.
Avati
