Re: [Gluster-devel] recomended library versions for glusterfs 1.3

[Amar S. Tumballi]

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 <address@hidden> 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
>
> address@hidden:/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
>
> address@hidden:/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
>
> address@hidden:/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:
>
> address@hidden:~# 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:
>
> address@hidden:~# setfattr -n user.foo -v bar /export/data/test
>
> address@hidden:~# 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:
>
> address@hidden:~# du -sh /export/data/var-www/obmbackup/*
> du: `/export/data/var-www/obmbackup/*': No such file or directory
>
> address@hidden:~# du -sh /export/data/var-www/*
> 4.0K    /export/data/var-www/obmbackup
>
>
> We check if the extended attributes are enabled:
>
> address@hidden:~# setfattr -n user.foo2 -v bar2 /export/data/test
>
> address@hidden:~# 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:
>
> address@hidden:~# du -sh /export/data/var-www/obmbackup/*
> du: `/export/data/var-www/obmbackup/*': No such file or directory
>
> address@hidden:~# du -sh /export/data/var-www/
> 8.0K    /export/data/var-www
>
> And again, we can check that the extended attributes are enabled:
>
> address@hidden:~# setfattr -n user.foo3 -v bar3 /export/data/test
>
> address@hidden:~# 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 <address@hidden> 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!