Re: [Gluster-devel] open-behind

[Vijay Bellur]

On 02/12/2013 11:48 AM, Anand Avati wrote:
> On Mon, Feb 11, 2013 at 7:53 PM, Vijay Bellur <address@hidden
> <mailto:address@hidden>> wrote:
>
>     On 02/12/2013 07:51 AM, Anand Avati wrote:
>
>
>
>         On Mon, Feb 11, 2013 at 4:15 AM, Raghavendra Bhat
>         <address@hidden <mailto:address@hidden>
>         <mailto:address@hidden <mailto:address@hidden>>> 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