Schomburg, You have 4 servers and one client. Each server has to export 2 directories /raid01a and /raid01b (FUSE do not play any role on the servers). On the client machine the glusterfs mounts using the client vol file combining all the exported directories. This would be a typical setup in your case. How is your setup? Can you mail the client vol file? According to your mail creation of directory fails. But creation/read/write of files are fine. Right? Krishna On Fri, Jan 2, 2009 at 5:01 PM, Jake Maul <jakemaul@xxxxxxxxx> wrote: > On Fri, Jan 2, 2009 at 3:55 AM, At Work <admin@xxxxxxxxxxx> wrote: >> Thank you for your rapid reply. Just one question: by "leave your fstab >> mount alone" do you mean leave it mount the xfs disk on startup? > > Yes. Mount your XFS partition via fstab as you normally would. > > As for the rest.... dunno what to tell ya. Maybe one of the glusterfs > devs can chime in with some ideas. > > Good luck, > Jake > >> This problem is odd to say the least - when I do a 'mount' after activating >> the glusterfs client and cluster on Leopard, I get the following: >> >> glusterfs on /Volumes/raid0102a (fusefs, local, synchronous) >> >> ...and on the Debian host server I get: >> >> fusectl on /sys/fs/fuse/connections type fusectl (rw) # seems to be a >> fuse connection - should fuse-accessible mounts go here? >> /dev/sdb1 on /raid01a type xfs (rw) # raid block a >> /dev/sdc1 on /raid01b type xfs (rw) # raid block b >> >> ...and in the glusterfs log I get: >> >> 2009-01-02 11:06:42 E [fuse-bridge.c:279:fuse_loc_fill] fuse-bridge: failed >> to search parent for 576 ((null)) >> 2009-01-02 11:06:42 E [fuse-bridge.c:703:do_chmod] glusterfs-fuse: 2: CHMOD >> 576 ((null)) (fuse_loc_fill() failed) >> 2009-01-02 11:06:42 E [fuse-bridge.c:279:fuse_loc_fill] fuse-bridge: failed >> to search parent for 576 ((null)) >> 2009-01-02 11:06:42 E [fuse-bridge.c:581:fuse_getattr] glusterfs-fuse: 1: >> GETATTR 576 (fuse_loc_fill() failed) >> 2009-01-02 11:08:16 E [fuse-bridge.c:279:fuse_loc_fill] fuse-bridge: failed >> to search parent for 578 ((null)) >> 2009-01-02 11:08:16 E [fuse-bridge.c:2193:fuse_getxattr] glusterfs-fuse: 2: >> GETXATTR (null)/578 (com.apple.FinderInfo) (fuse_loc_fill() failed) >> 2009-01-02 11:08:16 E [fuse-bridge.c:279:fuse_loc_fill] fuse-bridge: failed >> to search parent for 578 ((null)) >> 2009-01-02 11:08:16 E [fuse-bridge.c:2193:fuse_getxattr] glusterfs-fuse: 2: >> GETXATTR (null)/578 (com.apple.FinderInfo) (fuse_loc_fill() failed) >> 2009-01-02 11:08:17 E [fuse-bridge.c:279:fuse_loc_fill] fuse-bridge: failed >> to search parent for 578 ((null)) >> 2009-01-02 11:08:17 E [fuse-bridge.c:2193:fuse_getxattr] glusterfs-fuse: 0: >> GETXATTR (null)/578 (com.apple.FinderInfo) (fuse_loc_fill() failed) >> 2009-01-02 11:09:58 E [fuse-bridge.c:279:fuse_loc_fill] fuse-bridge: failed >> to search parent for 578 ((null)) >> 2009-01-02 11:09:58 E [fuse-bridge.c:581:fuse_getattr] glusterfs-fuse: 1: >> GETATTR 578 (fuse_loc_fill() failed) >> >> ...and the last two lines are repeated every few minutes. >> >> Am I correct in understanding that I have no need for FUSE on the Debian >> servers? There seems to be a bridge-failure of some sort going on here. >> >> >> >> On Jan 2, 2009, at 08:34 , Jake Maul wrote: >> >>> On the brick server (the content server... the one with the >>> XFS-formatted volume), FUSE is actually not used or even needed as far >>> as I can tell. Leave your fstab mount alone, and treat GlusterFS as a >>> pure replacement for NFS's /etc/exports. >>> >>> FUSE only comes into play on the client side, where it's no longer >>> relevant what the underlying filesystem is. If I'm reading you right, >>> your XServe is the client in this scenario. Perhaps Mac OSX's FUSE >>> implementation is strange somehow, I'm not familiar with it. >>> Otherwise, it sounds to me like you're doing it right. Sounds like >>> either a permissions problem or a bug somewhere (first guesses would >>> be Mac OSX's FUSE, or GlusterFS client on OSX). >>> >>> On Thu, Jan 1, 2009 at 11:55 PM, admin@xxxxxxxxxxx <admin@xxxxxxxxxxx> >>> wrote: >>>> >>>> Dear All, >>>> >>>> I'm afraid I'm a bit new to this. I hope I'm not missing the obvious, but >>>> in >>>> all the documentation I can't seem to find a clear answer to my problem. >>>> >>>> I have a head server (Leopard X serve) that will be used as a mount point >>>> for four sub-servers (Debian Etch) that each have two SATA RAID 5 blocks >>>> running an XFS filesystem. >>>> >>>> Before I switched to glusterfs, I would do an NFS export (/etc/exports) >>>> of >>>> the XFS filesystem mounted in /etc/fstab. I have since cancelled >>>> (commented >>>> out) the NFS export, but I am not quite sure what to do about the fstab: >>>> Should I mount the drives using this file, then export the filesystem >>>> using >>>> glusterfs? Or should it be glusterfs doing the mounting? What role does >>>> FUSE >>>> have in the mount operation? >>>> >>>> The RAID drives are at /dev/sdb and /dev/sdc, and their filesystems are >>>> accessible at /dev/sdb1 and /dev/sdc1 - should I be mounting these with >>>> glusterfs (instead of mounting them to a folder in the server root as I >>>> am >>>> doing presently)? >>>> >>>> With my present configuration, all works correctly if I mount the raid >>>> drives individually, yet when I mirror two drives across two servers >>>> using >>>> AFS things get wonky - I can upload files to a folder (and see that they >>>> have indeed been replicated to both drives), yet I am unable to create a >>>> new >>>> folder (it becomes an inaccessible icon). >>>> >>>> Thank you for any advice. >>>> >>>> Best, >>>> >>>> J.M. Schomburg. >>>> >>>> >>>> _______________________________________________ >>>> Gluster-devel mailing list >>>> Gluster-devel@xxxxxxxxxx >>>> http://lists.nongnu.org/mailman/listinfo/gluster-devel >>>> >>> >>> >>> _______________________________________________ >>> Gluster-devel mailing list >>> Gluster-devel@xxxxxxxxxx >>> http://lists.nongnu.org/mailman/listinfo/gluster-devel >> >> >> > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > http://lists.nongnu.org/mailman/listinfo/gluster-devel >
