[Gluster-devel] xfs, fstab, glusterfs
At Work
admin at matphot.com
Fri Jan 2 14:59:54 UTC 2009
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
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-devel/attachments/20090102/e8cf5c40/attachment-0003.html>
More information about the Gluster-devel
mailing list