gluster-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gluster-devel] open-behind


From: Anand Avati
Subject: Re: [Gluster-devel] open-behind
Date: Mon, 11 Feb 2013 22:18:03 -0800



On Mon, Feb 11, 2013 at 7:53 PM, Vijay Bellur <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>> 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?
 
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").

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]