Hi Vincent, Sebastien, Can you check now with patch 460, the compilation error you got for using old glibc should be gone with this. Also the error msgs from afr, saying op_ret = -1, op_errno = 38, should not come any more. Let me know what happens. Thanks and Regards, Amar On 8/17/07, Sebastien LELIEVRE <slelievre@xxxxxxxxxxxxxxxx> wrote: > > Hi everyone, > > I would like to add more infos to this situation. Here is the current > behaviour we're experiencing : > > Note : for those who would prefer, here is the pastebin of what follows: > http://glusterfs.pastebin.com/m4266582c > > We're using FUSE 2.6.5, GlusterFS 1.3 patch 457, libattr 2.4.7 and glibc > 2.3.2. kernel is 2.6.16.52 > > All servers export a '/export/data' directory > > Client mounts the glusterfs volume to /mnt/glusterfs with an afr *:3 > specification > > ## Client ## > > glusterfs 217G 7.1G 207G 4% /mnt/glusterfs > > root@glusterfs-client:/mnt# find /mnt/glusterfs/var-www/obmbackup -exec > file {} \; > /mnt/glusterfs/var-www/obmbackup: directory > /mnt/glusterfs/var-www/obmbackup/obmdb-20060104:202315-1.0.dump: ASCII > text > > root@glusterfs-client:/mnt# cat /var/log/glusterfs/glusterfs.log > 2007-08-17 07:27:26 E [afr.c:1442:afr_selfheal_getxattr_cbk] > tbs-clust-data-afr: > (path=/var-www/obmbackup/obmdb-20060104:202315-1.0.dump > child=tbs-clust-or2-data) op_ret=-1 op_errno=38 > > root@glusterfs-client:/mnt# touch /mnt/glusterfs/test > > ## server 1 ## > > Server 1 is the "consistent" brick. So it provides the files that should > be self-healed on other volumes. > for instance, as above with client: > > root@glusterfs-brick1:~# du -sh /export/data/var-www/obmbackup/* > 16M /export/data/var-www/obmbackup/obmdb-20060104:202315-1.0.dump > > > We check if the extended attributes are enabled: > > root@glusterfs-brick1:~# setfattr -n user.foo -v bar /export/data/test > > root@glusterfs-brick1:~# getfattr -n user.foo /export/data/test > getfattr: Removing leading '/' from absolute path names > # file: export/data/test > user.foo="bar" > > ## server 2 ## > > This server exported data directory is inconsistent. It should have been > self-healed with the client 'find' command above, but: > > root@glusterfs-brick2:~# du -sh /export/data/var-www/obmbackup/* > du: `/export/data/var-www/obmbackup/*': No such file or directory > > root@glusterfs-brick2:~# du -sh /export/data/var-www/* > 4.0K /export/data/var-www/obmbackup > > > We check if the extended attributes are enabled: > > root@glusterfs-brick2:~# setfattr -n user.foo2 -v bar2 /export/data/test > > root@glusterfs-brick2:~# getfattr -n user.foo2 /export/data/test > getfattr: Removing leading '/' from absolute path names > # file: export/data/test > user.foo2="bar2" > > > ## server 3 ## > > This server exported data directory is also inconsistent. It should have > been self-healed with the client 'find' command above, as brick2 should > have too, but the song remains the same: > > root@glusterfs-brick3:~# du -sh /export/data/var-www/obmbackup/* > du: `/export/data/var-www/obmbackup/*': No such file or directory > > root@glusterfs-brick3:~# du -sh /export/data/var-www/ > 8.0K /export/data/var-www > > And again, we can check that the extended attributes are enabled: > > root@glusterfs-brick3:~# setfattr -n user.foo3 -v bar3 /export/data/test > > root@glusterfs-brick3:~# getfattr -n user.foo3 /export/data/test > getfattr: Removing leading '/' from absolute path names > # file: export/data/test > user.foo3="bar3" > > Note that after editing this 'test' file (with 'vi' for instance), > extended attributes disappear > > If you need any more info, please ask ! > > Hope the code on which Amar is working would solve the issues above. > > Best Regards, > > Sebastien. > > Amar S. Tumballi a écrit : > > Hi Vincent, > > The versions you are using are perfectly fine. I am investigating about > the > > problems you have, with the help of Sebastien. Let me get back to you > once > > these issues are solved. > > > > -amar > > > > > > On 8/14/07, Vincent Régnard <vregnard@xxxxxxxxxxxxxxxx> wrote: > >> Hi all, > >> > >> My present gluster configuration is sometimes "freezing". I am > wondering > >> if this has to do with my library versions or the build process. My > >> glibc is pretty old (2.3.2) and I had to make a small patch to avoid > >> epoll problem as discussed somewhere here earlier: > >> > >> --- configure.ac.orig Thu Jul 5 15:49:08 2007 > >> +++ configure.ac Thu Jul 5 15:50:18 2007 > >> @@ -183,7 +183,7 @@ > >> AC_DEFINE(HAVE_BACKTRACE, 1, [define if found backtrace]) > >> fi > >> > >> -AC_CHECK_HEADERS([sys/epoll.h]) > >> +dnl AC_CHECK_HEADERS([sys/epoll.h]) > >> AC_CHECK_HEADERS([sys/xattr.h]) > >> > >> AC_SUBST(HAVE_IBVERBS) > >> > >> With latest (1.3.0 patch 457) I know have extended attribute problem > >> (source code does not compile) and I will certainly have to patch again > >> to bypass the trouble which certainly is not a good thing. > >> > >> I would like to know what are the "recomended" library versions for > >> gluster 1.3 (glibc, but also others such as libattr, fuse...) ? > >> > >> What would be similar recomendations for the linux kernel version and > >> for gcc compiler ? > >> > >> Thanks in advance for your comments. > >> > >> Vincent > >> > >> PS: I run > >> glusterfs 1.5patch403 > >> fuse 2.6.5 > >> libattr 2.4.7 > >> on linux kernel 2.6.16.52 > > -- Amar Tumballi Engineer - Gluster Core Team [bulde on #gluster/irc.gnu.org] http://www.zresearch.com - Commoditizing Supercomputing and Superstorage!
