Bug 783313 - Possible race between read-ahead and write
Possible race between read-ahead and write
Product: GlusterFS
Classification: Community
Component: read-ahead (Show other bugs)
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Raghavendra G
Anush Shetty
Depends On:
Blocks: 817967
  Show dependency treegraph
Reported: 2012-01-19 17:49 EST by Jeff Darcy
Modified: 2013-07-24 13:49 EDT (History)
3 users (show)

See Also:
Fixed In Version: glusterfs-3.4.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-24 13:49:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeff Darcy 2012-01-19 17:49:29 EST
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 08:09:43 EST
CHANGE: http://review.gluster.com/2666 (Fix race between read-ahead and write.) merged in master by Anand Avati (avati@gluster.com)
Comment 2 Anush Shetty 2012-06-04 01:56:13 EDT
This bug was filed as part of the review and was not able to reproduce it. So moving this to verified.

Note You need to log in before you can comment on or make changes to this bug.