| Summary: | [SAMBA-volfile] : Unable to mount samba share when a ping able ip that does not belong to the existing gluster cluster is provided before a valid ip in the glusterfs volfile server section in smb.conf | ||
|---|---|---|---|
| Product: | Red Hat Gluster Storage | Reporter: | Vivek Das <vdas> |
| Component: | samba | Assignee: | Raghavendra Talur <rtalur> |
| Status: | CLOSED NOTABUG | QA Contact: | storage-qa-internal <storage-qa-internal> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rhgs-3.2 | CC: | rhs-smb, rjoseph, rtalur |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-09 09:37:22 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Vivek Das
2016-11-05 14:10:52 UTC
Root Cause: There is a difference between the following two scenarios: a. Glusterd process is running on the given volfile_server entry b. Glusterd process is *not* running on the given volfile_server entry Scenario (b) is handled properly, if no response is received from the volfile_server entry, we move to the next entry in the list. In scenario (a), we have a Glusterd that belongs to a trusted storage pool that does not have any Volume corresponding to the volname given. In this case, we terminate the glfs_init process even before trying other entries in the list. This is based on the assumption that if one Glusterd process authoritatively says such a volume does not exist, it is true for the whole trusted storage pool and there is no need to verify the same from other Glusterd(s). Given below is the log messages to prove the same: [2016-11-07 15:14:38.715596] E [MSGID: 104021] [glfs-mgmt.c:552:glfs_mgmt_getspec_cbk] 0-gfapi: failed to get the 'volume file' from server [No such file or directory] [2016-11-07 15:14:38.715661] E [MSGID: 104007] [glfs-mgmt.c:633:glfs_mgmt_getspec_cbk] 0-glfs-mgmt: failed to fetch volume file (key:xcube) [Invalid argument] <------------- We got EINVAL not ENOTCONN [2016-11-07 15:14:38.715910] E [MSGID: 104024] [glfs-mgmt.c:735:mgmt_rpc_notify] 0-glfs-mgmt: failed to connect with remote-host: 192.168.21.5 (No such file or directory) [No such file or directory] [2016-11-07 15:14:38.715936] I [MSGID: 104044] [glfs-mgmt.c:837:mgmt_rpc_notify] 0-glfs-mgmt: connecting to next volfile server 192.168.21.4 at port 24007 with transport: tcp [2016-11-07 15:14:38.715961] I [MSGID: 101191] [event-epoll.c:659:event_dispatch_epoll_worker] 0-epoll: Exited thread with index 1 Severity for this bug is low considering the above information. Would like opinion of others regarding the same. (In reply to Raghavendra Talur from comment #3) > Root Cause: > In scenario (a), we have a Glusterd that belongs to a trusted storage pool > that does not have any Volume corresponding to the volname given. In this > case, we terminate the glfs_init process even before trying other entries in > the list. This is based on the assumption that if one Glusterd process > authoritatively says such a volume does not exist, it is true for the whole > trusted storage pool and there is no need to verify the same from other > Glusterd(s). I agree that if glusterd returns that no such volume exists then we need not look into other nodes. This list should only have ips/hostname belonging to the same trusted storage pool. > > Given below is the log messages to prove the same: > > > [2016-11-07 15:14:38.715596] E [MSGID: 104021] > [glfs-mgmt.c:552:glfs_mgmt_getspec_cbk] 0-gfapi: failed to get the 'volume > file' from server [No such file or directory] > [2016-11-07 15:14:38.715661] E [MSGID: 104007] > [glfs-mgmt.c:633:glfs_mgmt_getspec_cbk] 0-glfs-mgmt: failed to fetch volume > file (key:xcube) [Invalid argument] <------------- We got EINVAL not ENOTCONN > [2016-11-07 15:14:38.715910] E [MSGID: 104024] > [glfs-mgmt.c:735:mgmt_rpc_notify] 0-glfs-mgmt: failed to connect with > remote-host: 192.168.21.5 (No such file or directory) [No such file or > directory] > [2016-11-07 15:14:38.715936] I [MSGID: 104044] > [glfs-mgmt.c:837:mgmt_rpc_notify] 0-glfs-mgmt: connecting to next volfile > server 192.168.21.4 at port 24007 with transport: tcp Why are we seeing this message if we are not connecting to the next vlofile? (In reply to rjoseph from comment #4) > > Given below is the log messages to prove the same: > > > > > > [2016-11-07 15:14:38.715596] E [MSGID: 104021] > > [glfs-mgmt.c:552:glfs_mgmt_getspec_cbk] 0-gfapi: failed to get the 'volume > > file' from server [No such file or directory] > > [2016-11-07 15:14:38.715661] E [MSGID: 104007] > > [glfs-mgmt.c:633:glfs_mgmt_getspec_cbk] 0-glfs-mgmt: failed to fetch volume > > file (key:xcube) [Invalid argument] <------------- We got EINVAL not ENOTCONN > > [2016-11-07 15:14:38.715910] E [MSGID: 104024] > > [glfs-mgmt.c:735:mgmt_rpc_notify] 0-glfs-mgmt: failed to connect with > > remote-host: 192.168.21.5 (No such file or directory) [No such file or > > directory] > > [2016-11-07 15:14:38.715936] I [MSGID: 104044] > > [glfs-mgmt.c:837:mgmt_rpc_notify] 0-glfs-mgmt: connecting to next volfile > > server 192.168.21.4 at port 24007 with transport: tcp > > Why are we seeing this message if we are not connecting to the next vlofile? The reconnect thread does proceed to try next server but the main thread terminates because of previous error code. The current model does not give enough information to reconnect for it to stop retrying. Based on the above comments, it is agreed that it is not the right way to use volfile_server option. All the ip/hostnames given in the list should belong to same Gluster Trusted Storage Pool. Closing the bug for the same reason. |