[Gluster-devel] xfs, fstab, glusterfs
At Work
admin at matphot.com
Sat Jan 3 08:02:11 UTC 2009
What's more, I see that the proper permissions and UID are being
forwarded to the remote filesystem - as the user of the service
creating the files exists only on the "head" server, is it possible
that it is the remote server is refusing to do a mkdir and chown
directories? This would be odd, as it would seem logical that it
would be the mount-point server that would decide who gets to read or
write.
What of the "glusterfs-fuse" error I get every two seconds? Is this
in your domain, or should I be asking this of the FUSE developers?
Thanks, best.
> That's it exactly. As it stands I have glusterfs server (or its
> server.vol file) on the sub-servers setting up (and exporting?) the
> bricks, and the OS X uses only the client.vol file to import and
> assemble the remote bricks into a cluster. Also, yes, the problems
> are as you say: I can read/write files, but I cannot create/upload/
> rename directories.
>
> Here is a copy of the server.vol files from two servers:
>
> matserve01:
>
> volume posix01a
> type storage/posix
> option directory /raid01a/clients
> end-volume
>
> volume raid01a
> type features/locks
> subvolumes posix01a
> end-volume
>
> volume posix01b
> type storage/posix
> option directory /raid01b/clients
> end-volume
>
> volume raid01b
> type features/locks
> subvolumes posix01b
> end-volume
>
>
> ### Add network serving capability to above exports.
> volume server
> type protocol/server
> option transport-type tcp
> subvolumes raid01a raid01b
> option auth.addr.raid01a.allow 192.168.1.* # Allow access to
> "raid01a" volume
> option auth.addr.raid01b.allow 192.168.1.* # Allow access to
> "raid01b" volume
> end-volume
>
>
> matserve02:
>
> volume posix02a
> type storage/posix
> option directory /raid02a/clients
> end-volume
>
> volume raid02a
> type features/locks
> subvolumes posix02a
> end-volume
>
> volume posix02b
> type storage/posix
> option directory /raid02b/clients
> end-volume
>
> volume raid02b
> type features/locks
> subvolumes posix02b
> end-volume
>
> ### Add network serving capability to above exports.
> volume server
> type protocol/server
> option transport-type tcp
> subvolumes raid02a raid02b
> option auth.addr.raid02a.allow 192.168.1.* # Allow access to
> "raid02a" volume
> option auth.addr.raid02b.allow 192.168.1.* # Allow access to
> "raid02b" volume
> end-volume
>
> ...and the client.vol file from the OS X server.
>
> ### Add client feature and attach to remote subvolume of server1
>
> # import RAID a's on matserve01 & matserve02
>
> volume rRaid01a
> type protocol/client
> option transport-type tcp/client
> option remote-host 192.168.1.6 # IP address of the remote brick
> option remote-subvolume raid01a # name of the remote volume
> end-volume
>
> volume rRaid02a
> type protocol/client
> option transport-type tcp/client
> option remote-host 192.168.1.7 # IP address of the remote brick
> option remote-subvolume raid02a # name of the remote volume
> end-volume
>
> ## add c, d, e, etc sections as bays expand for each server
> ###################
>
> ### Add client feature and attach to remote subvolume of server2
>
> # combine raid a's
> volume cluster0102a
> type cluster/afr
> subvolumes rRaid01a rRaid02a
> end-volume
>
> ## add c, d, e, etc sections as bays expand for each server
> ###################
>
>
> ...you may notice that I am for the time being assembling but one
> cluster (a) - for testing purposes.
>
> Does all this seem correct to you?
>
>
> On Jan 2, 2009, at 14:17 , Krishna Srinivas wrote:
>
>> 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 at gmail.com> wrote:
>>> On Fri, Jan 2, 2009 at 3:55 AM, At Work <admin at matphot.com> 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 at matphot.com
>>>>> <admin at matphot.com>
>>>>> 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 at nongnu.org
>>>>>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Gluster-devel mailing list
>>>>> Gluster-devel at nongnu.org
>>>>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Gluster-devel mailing list
>>> Gluster-devel at nongnu.org
>>> http://lists.nongnu.org/mailman/listinfo/gluster-devel
>>>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at nongnu.org
> http://lists.nongnu.org/mailman/listinfo/gluster-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20090103/d3230a98/attachment-0003.html>
More information about the Gluster-devel
mailing list