Looks like we have introduced a bug, shall get back after the fix. Krishna On Tue, Jun 24, 2008 at 12:25 AM, Christopher Hawkins <chawkins at bplinux.com> wrote: > There is some new behavior after some more testing so I'll start a new thread. Let's forget the old one for now as that is possibly unrelated. > > Using: > glusterfs 1.4.0qa22 built on Jun 22 2008 23:48:33 > Repository revision: glusterfs--mainline--3.0--patch-197 > And fuse: fuse-2.7.3glfs10 > > I have a client that AFR's two servers. Very simple configs, just a single brick (storage1) on each server and this on the client - > > volume master1 > type protocol/client > option transport-type tcp/client # for TCP/IP transport > option remote-host 192.168.20.150 # IP address of the remote brick > option transport-timeout 5 > option remote-subvolume storage1 # name of the remote volume > end-volume > > volume master2 > type protocol/client > option transport-type tcp/client # for TCP/IP transport > option remote-host 192.168.20.151 # IP address of the remote brick > option transport-timeout 5 > option remote-subvolume storage1 # name of the remote volume > end-volume > > volume data-afr > type cluster/afr > subvolumes master1 master2 > end-volume > > Everything mounts no problem. Now on the client I do this inside the gluster mount: "echo somedata > afile" to create afile. And both servers get a copy of afile with the correct data inside. There are two interesting things going on... One, I can't see any xattr versioning information: > > root at master1 cluster # getfattr -n trusted.glusterfs.version /cluster/afile > /cluster/afile: trusted.glusterfs.version: No such attribute > > Two, on every write to the file, the servers each log this in glusterfsd.log: > 2008-06-23 13:06:57 W [posix.c:1546:posix_incver] storage1: /cluster/afile: No data available > > But I can set it from the client like so: "setfattr -n trusted.glusterfs.version -v 5 afile" and now: > > root at master1 cluster # getfattr -n trusted.glusterfs.version /cluster/afile > getfattr: Removing leading '/' from absolute path names > # file: cluster/afile > trusted.glusterfs.version="5" > > So it looks like xattr support is working fine, and now when I echo more data into afile, the servers do not log any errors and the file version gets incremented correctly: > > root at master1 cluster # getfattr -n trusted.glusterfs.version /cluster/afile > getfattr: Removing leading '/' from absolute path names > # file: cluster/afile > trusted.glusterfs.version="6" > > Any ideas on why gluster is not creating the xattrs by itself? > > Thanks, > Chris > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users >