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
>