Bug 783313

Summary: Possible race between read-ahead and write
Product: [Community] GlusterFS Reporter: Jeff Darcy <jdarcy>
Component: read-aheadAssignee: Raghavendra G <rgowdapp>
Status: CLOSED CURRENTRELEASE QA Contact: Anush Shetty <ashetty>
Severity: high Docs Contact:
Priority: unspecified    
Version: mainlineCC: amarts, gluster-bugs, rfortier
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: glusterfs-3.4.0 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-24 17:49:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 817967    

Description Jeff Darcy 2012-01-19 22:49:29 UTC 
Description of problem:

Currently, it's possible for a write to occur while a read-ahead is in progress, and nothing is done to interrupt or cancel that read-ahead.  As a result, a user read which is fully subsequent to that write (even if it's O_SYNC) could still get the read-ahead data which is now stale.

How reproducible:

It's a race, found by inspection, so it's probably pretty hard to hit (hasn't been observed in practice except by stopping things in a debugger).  It might be possible to construct a log-tailing test case, as that would leave one process reading just behind where another was writing on the same client.  Meanwhile, since read-ahead is just a performance optimization, it should be safe to disable it when the risk can be anticipated.
Comment 1 Anand Avati 2012-01-30 13:09:43 UTC 
CHANGE: http://review.gluster.com/2666 (Fix race between read-ahead and write.) merged in master by Anand Avati (avati)
Comment 2 Anush Shetty 2012-06-04 05:56:13 UTC 
This bug was filed as part of the review and was not able to reproduce it. So moving this to verified.