I forgot to post some details:
the server running the client-side replication is a xen virtuell server.

/etc/fstab:
# GFS
/etc/glusterfs/mount-backup01-client_repl.vol           /GFS/backup01           glusterfs       noatime,defaults        0 0

kernel: Linux version 2.6.27.19-5-xen

fuse:
fuse-2.7.2-61.14
libfuse2-2.7.2-61.14

the server is running rsynd on the glusterfs share.
the first time the error appears, when rsynd was started and the first data are received by the rsync daemon

this error appears multiple each second in the logfile on client side:
[2010-02-22 10:17:44] E [afr.c:179:afr_read_child] mirror: invalid argument: inode
[2010-02-22 10:17:45] E [afr.c:179:afr_read_child] mirror: invalid argument: inode
[2010-02-22 10:17:45] E [afr.c:179:afr_read_child] mirror: invalid argument: inode
[2010-02-22 10:17:45] E [afr.c:179:afr_read_child] mirror: invalid argument: inode
[2010-02-22 10:17:45] E [afr.c:179:afr_read_child] mirror: invalid argument: inode
[2010-02-22 10:17:45] E [afr.c:179:afr_read_child] mirror: invalid argument: inode
[2010-02-22 10:17:45] E [afr.c:179:afr_read_child] mirror: invalid argument: inode
[2010-02-22 10:17:45] E [afr.c:179:afr_read_child] mirror: invalid argument: inode
[2010-02-22 10:17:45] E [afr.c:179:afr_read_child] mirror: invalid argument: inode
[2010-02-22 10:17:45] E [afr.c:179:afr_read_child] mirror: invalid argument: inode
[2010-02-22 10:17:45] E [afr.c:179:afr_read_child] mirror: invalid argument: inode
[2010-02-22 10:17:46] E [afr.c:179:afr_read_child] mirror: invalid argument: inode


please look also there in the mailinglist:
http://www.mail-archive.com/gluster-devel@nongnu.org/msg06911.html


there are two gfs servers exporting diskspace using this configuration:

# export-backup01-client_repl
# gfs-01-01 /GFS/backup01
# gfs-01-02 /GFS/backup01

volume posix
  type storage/posix
  option directory /GFS/backup01
end-volume

volume locks
  type features/locks
  subvolumes posix
end-volume

volume writebehind
  type performance/write-behind
  option cache-size 4MB
  option flush-behind on
  subvolumes locks
end-volume

volume backup01
  type performance/io-threads
  option thread-count 8
  subvolumes writebehind
end-volume

volume server
  type protocol/server
  option transport-type tcp
  option transport.socket.listen-port 6996
  option auth.addr.backup01.allow 192.168.11.*
  subvolumes backup01
end-volume


and a other server which makes client-side replication with this configuration:
volume gfs-01-01-vol
  type protocol/client
  option transport-type tcp
  option remote-host gfs-01-01
  option remote-port 6996
  option remote-subvolume backup01
end-volume

volume gfs-01-02-vol
  type protocol/client
  option transport-type tcp
  option remote-host gfs-01-02
  option remote-port 6996
  option remote-subvolume backup01
end-volume

volume mirror
  type cluster/replicate
  subvolumes gfs-01-01-vol gfs-01-02-vol
end-volume

volume readahead
  type performance/read-ahead
  option page-size 1MB
  option page-count 4
  subvolumes mirror
end-volume

volume writebehind
  type performance/write-behind
  option cache-size 1024KB
  option flush-behind on
  subvolumes readahead
end-volume

volume cache
  type performance/io-cache
  option cache-size 128MB
  subvolumes writebehind
end-volume

Vikas, any updates?

This bug was present in 3.0.0 but was fixed as part of the self-heal memory corruption patches.

Please reopen if seen with 3.0.2 or 3.0.3