anand.avati at gmail.com
Tue Feb 12 06:18:03 UTC 2013
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:
>> 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gluster-devel