[Gluster-devel] open-behind

[Anand Avati]

On Mon, Feb 11, 2013 at 7:53 PM, Vijay Bellur <vbellur at redhat.com> wrote:

> On 02/12/2013 07:51 AM, Anand Avati wrote:
>
>>
>>
>> On Mon, Feb 11, 2013 at 4:15 AM, Raghavendra Bhat <rabhat at redhat.com
>> <mailto:rabhat at redhat.com>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20130211/2c7124aa/attachment-0001.html>