Bug 762286 (GLUSTER-554) - Replicate only writes posix locks to first subvolume
Summary: Replicate only writes posix locks to first subvolume
Keywords:
Status: CLOSED NOTABUG
Alias: GLUSTER-554
Product: GlusterFS
Classification: Community
Component: replicate
Version: 3.0.0
Hardware: All
OS: All
medium
medium
Target Milestone: ---
Assignee: Vikas Gorur
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-01-21 20:02 UTC by Joe Julian
Modified: 2010-02-16 06:50 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Regression: RTNR
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Description Joe Julian 2010-01-21 20:02:54 UTC 
Replicate only writes locks to the first subvolume. This behavior causes a single point of failure. At minimum there should be an option to replicate the posix locks to all subvolumes.
Comment 1 Vikas Gorur 2010-01-22 03:16:49 UTC 
Replicate indeed sends the posix locks request to all its subvolumes.

Can you clarify why you arrived at the opposite conclusion?
Comment 2 Jeff Darcy 2010-01-22 11:45:33 UTC 
That one was probably my fault.  I observed that afr_lk only seemed to be sending the request to one subvolume.  However, I now see that the callback sends it to the next, etc.  Is there any reason this needs to be done sequentially rather than in parallel?
Comment 3 Anand Avati 2010-01-23 08:36:15 UTC 
> That one was probably my fault.  I observed that afr_lk only seemed to be
> sending the request to one subvolume.  However, I now see that the callback
> sends it to the next, etc.  Is there any reason this needs to be done
> sequentially rather than in parallel?

Acquiring locks in parallel can lead to a race among multiple clients both getting granted conflicting locks. Sequential acquisition is safe.

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