On Mon, Feb 11, 2013 at 7:53 PM, Vijay Bellur <vbel...@redhat.com> wrote:
> On 02/12/2013 07:51 AM, Anand Avati wrote: > >> >> >> On Mon, Feb 11, 2013 at 4:15 AM, Raghavendra Bhat <rab...@redhat.com >> <mailto:rab...@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
_______________________________________________ Gluster-devel mailing list Gluster-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/gluster-devel
