vbellur at redhat.com
Tue Feb 12 03:53:38 UTC 2013
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
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.
More information about the Gluster-devel