Bug 989038 - backupvolfile-server does not work with automount
backupvolfile-server does not work with automount
Status: CLOSED DUPLICATE of bug 986429
Product: GlusterFS
Classification: Community
Component: unclassified (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Vijay Bellur
Depends On: 986429
  Show dependency treegraph
Reported: 2013-07-26 21:24 EDT by mark
Modified: 2014-06-06 03:09 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-06-06 03:09:23 EDT
Type: Bug
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 mark 2013-07-26 21:24:49 EDT
Description of problem:
Using autofs to mount gluster volumes, the backupvolfile=$backup-server option is ineffective, though this works correctly when calling mount -t glusterfs directly from the command line. Specifically, given an automount entry in as:

volume  -fstype=glusterfs,backupvolfile-server=server2 server1:volume

If server1 is down, volume will not mount. However, issuing

mount -t glusterfs -o backupvolfile-server=server2 server1:volume /mnt/volume

DOES work. For a specific case, here are relevant lines from the glusterfs log file (the actual mount point is /misc/shared in this case):

[2013-07-27 00:25:44.848810] E [socket.c:2157:socket_connect_finish] 0-glusterfs: connection to failed (Connection refused)
[2013-07-27 00:25:44.848893] E [glusterfsd-mgmt.c:1851:mgmt_rpc_notify] 0-glusterfsd-mgmt: failed to connect with remote-host: Transport endpoint is not connected
[2013-07-27 00:25:44.857882] E [fuse-bridge.c:4973:init] 0-fuse: Mountpoint /misc/shared seems to have a stale mount, run 'umount /misc/shared' and try again.
[2013-07-27 00:25:44.857934] E [xlator.c:390:xlator_init] 0-fuse: Initialization of volume 'fuse' failed, review your volfile again

Version-Release number of selected component (if applicable):

This is happening with gluster v 3.4.0-3, installed into rhel6.4 64-bit, as well as on Fedora 18 clients. All of the servers are rhel6.4 x86_64.
rpm -qa|grep gluster reports on F18:


How reproducible:
1. Create a replicated gluster volume.
2. Set up an automount map with a primary server and backupvolfile-server pointing to an alternate.
3. Take the primary gluster server off line
4. Attempt to mount the volume on a client via automounter.

Actual results:
Volume does not mount.

Expected results:
Volume should be mounted from the backup server.

Additional info:
The logfile notation of "Mountpoint /misc/shared seems to have a stale mount, run 'umount /misc/shared'" was suspicious, so I patched /sbin/mount.glusterfs to unmount before trying the backup server:
--- mount.glusterfs~    2013-07-26 20:25:34.028813360 -0400
+++ mount.glusterfs     2013-07-26 20:26:45.849772714 -0400
@@ -227,7 +227,7 @@
         if [ -n "$cmd_line1" ]; then
             cmd_line1=$(echo "$cmd_line1 $mount_point");
+            umount $mount_point

and with this, automounting from the backup server works ~80% of the time.
Comment 1 Niels de Vos 2014-06-06 03:09:23 EDT
Bug 986429 has been used to implement an other solution that should solve this. I'm closing this bug as a duplicate. Please test a version that contains the changes of Bug 986429.

In case the changes do not work as expected, feel free to reopen this bug (move it to the NEW status) and explain what's not working.

*** This bug has been marked as a duplicate of bug 986429 ***

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