On 01/09/2014 10:17 PM, Jia-Hao Chen wrote:
Hi, I am doing a preliminary test of using Gluster NFS to replace our old NFS server. I created a replicate volume with 2 bricks and setup up CTDB to manage IP takeover. My test is very simple. Copy a large file to the nfs mount, and unplug power cord while the file is copying. After couples of seconds, the survival node take over IP address successfully and nfs client established a new connection to it. Everything seems to be fine. But the copy didn't continue due to an inode lock still granted to someone. After around 15~20 minutes, the lock was gone and copy continues. But after copy finished, the checksum of the file is wrong. I repeatedly test this case several times but the result are the same. Have anyone known how to setup a high-availability Gluster NFS server correctly? or can give me some hint about it?
This does not look right and I was unable to recreate the problem with simple tests in my setup. Can you please file a bug with more description at:
https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS Having a bug will help in tracking the issue better. Thanks, Vijay _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users
