Daniel, Can you confirm if you backend filesystem is proper? Can you delete the file from the backend? Gluster does not return EROFS in any of the cases you described. Also, try setting a lower ping-timeout and see if it helps in case of crosscable failover test. Avati On Tue, Jun 14, 2011 at 12:58 PM, Daniel Manser <daniel at clienta.ch> wrote: > Hi Whit, > > Thanks for your reply. > > > I do know that it's not the Gluster-standard thing to use a crossover >> link. >> (Seems to me it's the obvious best way to do it, but it's not a >> configuration they're committed to.) It's possible that if you were doing >> your replication over the LAN rather than the crossover that Gluster would >> handle a disconnected system better. Might be worth testing. >> > > It is still the same, even if no crossover cable is used and all traffic > goes through an ethernet switch. The client can't write to the gluster > volume anymore. I discovered that the NFS volume seems to be read-only in > this state: > > client01:~# rm debian-6.0.1a-i386-DVD-1.iso > rm: cannot remove `debian-6.0.1a-i386-DVD-1.iso': Read-only file system > > So all traffic goes through one interface (NFS to the client, glusterfs > replication, corosync). > > I can reproduce the issue with the NFS client on VMware ESXi and with the > NFS client on my Linux desktop. > > My config: > > Volume Name: vmware > Type: Replicate > Status: Started > Number of Bricks: 2 > Transport-type: tcp > Bricks: > Brick1: gluster1:/mnt/gvolumes/vmware > Brick2: gluster2:/mnt/gvolumes/vmware > > Regards, > Daniel > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://gluster.org/cgi-bin/mailman/listinfo/gluster-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://gluster.org/pipermail/gluster-users/attachments/20110614/5234771c/attachment.htm>
