Hi! It should not be behaving that way. The client should work seamlessly. inline... On 9/7/07, August R. Wohlt <glusterfs@xxxxxxxxxxx> wrote: > Hi all - > > I have a setup based on this : > http://www.gluster.org/docs/index.php/GlusterFS_High_Availability_Storage_with_GlusterFS<http://www.gluster.org/docs/index.php/GlusterFS_High_Availability_Storage_with_GlusterFS> > but with only 2 machines. Effectively just a mirror (glusterfsd > configuration below). 1.3.1 client and server. > > The problem I am seeing is that if I start up one side of the afr and the > other side is down, I can only read and write to files that are already > there. If I try to create a new file, the glusterfsd logs show this: I am trying to understand your setup. The wiki setup says there are 3 servers, is yours same? because you say you start one side of afr and other side is down. Pasting spec files will help. Thanks Krishna > > 07-09-07 11:39:00 D [common-utils.c:194:gf_resolve_ip] resolver: flushing > DNS cache > 2007-09-07 11:39:00 D [tcp-client.c:142:tcp_connect] brick-ds-bak: connect > on 9 in progress (non-blocking) > 2007-09-07 11:39:00 E [tcp-client.c:171:tcp_connect] brick-ds-bak: > non-blocking connect() returned: 111 (Connection refused) > 2007-09-07 11:39:00 W [client-protocol.c:344:client_protocol_xfer] > brick-ds-bak: not connected at the moment to submit frame type(0) op(34) > 2007-09-07 11:39:00 D [inode.c:297:__destroy_inode] brick/inode: destroy > inode(0) [@0x148e8200] > 2007-09-07 11:39:17 D [client-protocol.c:4211:client_protocol_reconnect] > brick-ds-bak: attempting reconnect > > and the file creation just never returns. ie, if i mount this mirror setup > on /brick and do: touch /brick/non_exist, an strace of tha tprocess just > shows it hanging in : > > open("/brick/non_exist", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666 > > So my question is whether this is indended behavior? The wiki page makes it > sound like this is an HA setup, but if one side goes down and that makes the > remaining node useless, it's not much use as an HA setup. Am I missing > something critical here? > > > thanks, > august > > ------------ > client (mounted on /brick): > > > volume brick > type protocol/client > option transport-type tcp/client > option remote-host 192.168.16.126 > option remote-subvolume brick > option remote-port 16 > end-volume > > > server : > > volume brick-ds > type storage/posix > option directory /.brick-ds > end-volume > > volume brick-ns > type storage/posix > option directory /.brick-ns > end-volume > > > volume brick-ds-bak > type protocol/client > option transport-type tcp/client > option remote-host 192.168.16.254 > option remote-port 16 > option remote-subvolume brick-ds > end-volume > > volume brick-ns-bak > type protocol/client > option transport-type tcp/client > option remote-host 192.168.16.254 > option remote-port 16 > option remote-subvolume brick-ns > end-volume > > > volume brick-ds-afr > type cluster/afr > subvolumes brick-ds brick-ds-bak > option replicate *:2 > end-volume > volume brick-ns-afr > type cluster/afr > subvolumes brick-ds brick-ds-bak > option replicate *:2 > end-volume > > volume brick-unify > type cluster/unify > subvolumes brick-ds-afr > option namespace brick-ns-afr > option scheduler rr > end-volume > > > volume brick > type performance/io-threads > option thread-count 4 > option cache-size 64MB > subvolumes brick-unify > end-volume > > volume server > type protocol/server > option transport-type tcp/server > option bind-address 192.168.16.126 > option auth.ip.brick-ds.allow 192.168.16.* > option auth.ip.brick-ns.allow 192.168.16.* > option auth.ip.brick.allow 192.168.16.* > option listen-port 16 > subvolumes brick > end-volume > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel >
