Re: [Gluster-devel] open-behind

[Vijay Bellur]

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?

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.

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.

-Vijay