Bug 763825 (GLUSTER-2093) - volumes cannot start when one node in a replicated setup is down
Summary: volumes cannot start when one node in a replicated setup is down
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: GLUSTER-2093
Product: GlusterFS
Classification: Community
Component: nfs
Version: 3.1.0
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Shehjar Tikoo
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-11-11 19:58 UTC by Allen Lu
Modified: 2015-12-01 16:45 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Regression: RTP
Mount Type: nfs
Documentation: DNR
CRM:
Verified Versions:
Embargoed:

Attachments (Terms of Use)

Description Allen Lu 2010-11-11 19:58:11 UTC 
if one server is taken down, volumes cannot start. 
The issue is NFS server checks for existance of all subvolumes before 
it would register with portmap. NFS server would wait forever at trying 
to ping all subvolumes. The NFS server should go on if it can find one of the replicated volume.
Comment 1 Shehjar Tikoo 2010-11-15 08:37:23 UTC 
What gluster commands did you use? 

I cannot understand what you mean by, "if one server is taken down, volumes cannot start."

Are you saying that the "gluster volume start <volname>" command does not start nfs server in case a physical server containing a brick is down?
Comment 2 Anand Avati 2010-11-18 11:12:24 UTC 
PATCH: http://patches.gluster.com/patch/5748 in master (nfs: treat GF_EVENT_CHILD_CONNECTING as subvolume up status)
Comment 3 Anand Avati 2010-11-25 11:35:28 UTC 
PATCH: http://patches.gluster.com/patch/5782 in master (nfs: Export subvolumes on per-subvolume CHILD-UP)
Comment 4 Anand Avati 2010-12-03 15:03:34 UTC 
PATCH: http://patches.gluster.com/patch/5786 in master (nfs: Start nfs process even if portmap registration fails)
Note You need to log in before you can comment on or make changes to this bug.