Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 910239

Summary: open behind issue
Product: [Community] GlusterFS Reporter: Raghavendra Bhat <rabhat>
Component: quick-readAssignee: Raghavendra G <rgowdapp>
Status: CLOSED WONTFIX QA Contact:
Severity: unspecified Docs Contact:
Priority: medium    
Version: mainlineCC: gluster-bugs
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-27 08:27:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
program to reproduce the issue none

Description Raghavendra Bhat 2013-02-12 05:49:03 UTC
Created attachment 696371 [details]
program to reproduce the issue

Description of problem:

Currently open-behind delays the open call by unwinding success to the above xlators and sending open only when necessary (for fops like readv and fstat open is not sent, instead anonymous fd is used for sending those fops).

But suppose there are 2 clients doing operations like this:

client 1 -> open a file
client 1 -> sleep
client 2 -> delete the file (client 1 is still not doing anything on the fd)
client 1 -> read from the fd

Without open-behind client1 is able to read the contents of the file even after it gets unlinked. But with open-behind even though open is successful, the application's read attempt from client1 fails getting EUCLEAN (Structure needs cleaning).

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Create a volume, start it and mount it via 2 clients
2. create a file "data" on the mount point with some data in it
3. On one client execute the program attached
4. When the attached program says unlink, remove the file "data" from client2 immedietly (i.e the file should be unlinked while the program running on client1 is still sleeping and has not attempted read)

  
Actual results:
read from the application says Structure needs cleaning

Expected results:
file's data should be available upon read

Additional info:

Comment 1 Raghavendra G 2013-05-27 08:27:31 UTC
This is a known issue. Synchronization across clients is not supported. The problem is very similar to cache coherency issues. Closing this bug.