[Gluster-users] [Gluster-devel] Volume Create Failed

Thing thing.thing at gmail.com
Tue May 6 02:47:37 UTC 2014


Using iptraf and dd to crate a 2gb file it looks like data is being
transferred from port 970 to port 49152.  yet the docs say 34865?

?




On 6 May 2014 14:20, Thing <thing.thing at gmail.com> wrote:

> Seem iptables is blocking sync, so what have I missed please?
>
> ========
> Chain IN_public_allow (1 references)
> target     prot opt source               destination
> ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp
> dpt:2049 ctstate NEW
> ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22
> ctstate NEW
> ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp
> dpts:24009:24012 ctstate NEW
> ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:111
> ctstate NEW
> ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp
> dpts:34865:34867 ctstate NEW
> ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:111
> ctstate NEW
> ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp
> dpt:24007 ctstate NEW
> =======
>
>
> On 6 May 2014 13:18, Thing <thing.thing at gmail.com> wrote:
>
>> For RHEL6.5 what else do I need to install to allow mount to work?
>>
>> =======8><----========
>> Installed:
>>   glusterfs.x86_64
>> 0:3.4.0.57rhs-1.el6_5
>>
>>
>> Complete!
>> [root at 8kxl72s ~]# mount -t glusterfs rhel7rc-004.ods.vuw.ac.nz:gv0
>> /mnt/gluster1-gv0
>> mount: unknown filesystem type 'glusterfs'
>> ======
>>
>>
>>
>>  On 6 May 2014 12:28, Cary Tsai <f4lens at gmail.com> wrote:
>>
>>>  # gluster peer status
>>> Number of Peers: 3
>>>
>>> Hostname: us-east-2
>>> Uuid: 3b102df3-74a7-4794-b300-b93bccfe8072
>>> State: Peer in Cluster (Connected)
>>>
>>> Hostname: us-west-1
>>> Uuid: 98906a76-dd5b-4db9-99d5-1d51b1ee3d2a
>>> State: Peer in Cluster (Connected)
>>>
>>> Hostname: us-west-2
>>> Uuid: 16eff965-ec88-4d12-adea-8512350bdaa7
>>> State: Peer in Cluster (Connected)
>>>
>>> # gluster volume  create  snoopy replica 4 transport tcp 192.168.255.5:/brick1
>>> us-east-2:/brick1 us-west-1:/brick1 us-west-2:/brick1 force
>>> volume create: snoopy: failed
>>> -------------------------------------------------------------------
>>> When I check the debug log, /var/log/glusterfs/cli.log , it shows:
>>>
>>> [2014-05-06 00:17:29.988414] W [rpc-transport.c:175:rpc_transport_load]
>>> 0-rpc-transport: missing 'option transport-type'. defaulting to "socket"
>>> [2014-05-06 00:17:29.988909] I [socket.c:3480:socket_init] 0-glusterfs:
>>> SSL support is NOT enabled
>>> [2014-05-06 00:17:29.988930] I [socket.c:3495:socket_init] 0-glusterfs:
>>> using system polling thread
>>> [2014-05-06 00:17:30.022545] I
>>> [cli-cmd-volume.c:392:cli_cmd_volume_create_cbk] 0-cli: Replicate cluster
>>> type found. Checking brick order.
>>> [2014-05-06 00:17:30.022706] I
>>> [cli-cmd-volume.c:304:cli_cmd_check_brick_order] 0-cli: Brick order okay
>>> [2014-05-06 00:17:30.273942] I
>>> [cli-rpc-ops.c:805:gf_cli_create_volume_cbk] 0-cli: Received resp to create
>>> volume
>>> [2014-05-06 00:17:30.274027] I [input.c:36:cli_batch] 0-: Exiting with:
>>> -1
>>>
>>> What did I do wrong? Is more details I can read to figure out why my
>>> volume create failed?
>>> Thanks
>>>
>>> _______________________________________________
>>> Gluster-users mailing list
>>> Gluster-users at gluster.org
>>> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140506/d44e883c/attachment.html>


More information about the Gluster-users mailing list