Bug 989038 - backupvolfile-server does not work with automount
Summary: backupvolfile-server does not work with automount
Keywords:
Status: CLOSED DUPLICATE of bug 986429
Alias: None
Product: GlusterFS
Classification: Community
Component: unclassified
Version: 3.4.0
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Vijay Bellur
QA Contact:
URL:
Whiteboard:
Depends On: 986429
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-07-27 01:24 UTC by mark
Modified: 2014-06-06 07:09 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-06 07:09:23 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Embargoed:


Attachments (Terms of Use)

Description mark 2013-07-27 01:24:49 UTC
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 192.168.10.228:24007 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:

glusterfs-server-3.4.0-3.fc18.x86_64
glusterfs-3.4.0-3.fc18.x86_64
glusterfs-fuse-3.4.0-3.fc18.x86_64


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 @@
         err=1;
         if [ -n "$cmd_line1" ]; then
             cmd_line1=$(echo "$cmd_line1 $mount_point");
+            umount $mount_point
             $cmd_line1;
             err=0;

and with this, automounting from the backup server works ~80% of the time.

Comment 1 Niels de Vos 2014-06-06 07:09:23 UTC
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.