[Bugs] [Bug 1222678] New: backupvolfile-server, backup-volfile-servers options in /etc/fstab / list of volfile-server options on command line ignored when mounting

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1222678

            Bug ID: 1222678
           Summary: backupvolfile-server, backup-volfile-servers options
                    in /etc/fstab / list of volfile-server options on
                    command line ignored when mounting
           Product: GlusterFS
           Version: mainline
         Component: core
          Severity: high
          Assignee: bugs at gluster.org
          Reporter: ueberall at projektzentrisch.de
                CC: bugs at gluster.org, gluster-bugs at redhat.com



Created attachment 1026857
  --> https://bugzilla.redhat.com/attachment.cgi?id=1026857&action=edit
Required detailed information as per gluster bug reporting guidelines

Description of problem:
If the first specified volfile-server is not responding while mounting a
volume, specified backup servers are *not contacted at all*.

Version-Release number of selected component (if applicable):
3.6.3 (unofficial Ubuntu 14.04.2 LTS build based on Debian source packages)

How reproducible:
*Always* by ensuring that first --volfile-server passed to /usr/sbin/glusterfs
is not responding.

Steps to Reproduce:
1. Modify a working /etc/fstab entry so that the server referenced on the left
is not responding (alternatively, shut down the named server)
E.g., in the following, it is sufficient to ensure that 10.0.3.83 is
unavailable while 10.0.3.81, 10.0.3.82 are up and running just fine:
10.0.3.83:/gvol00 /mirrored/gluster glusterfs
defaults,_netdev,backup-volfile-servers=10.0.3.81:10.0.3.82 0 0
2. Execute "sudo umount /mirrored/gluster; sudo mount /mirrored/gluster" to
ensure that the above configuration will take effect; the second command will
fail.
3. Counter-example: "Revive" 10.0.3.83 or just permute the IP addresses above
so that a working node is contacted first and re-run the previous command which
will now succeed.

Actual results:
The volume can be mounted on the client iff and only iff the first
volfile-server is available at that point in time.

Expected results:
All specified volfile-servers are contacted at least once when trying to mount
the volume in question (regardless of an existing fetch-attempts option which
does not change the behaviour)

Additional info:
Please refer to the attached files which contain details, statedumps.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.