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 <[email protected]> wrote:
On Fri, Jan 2, 2009 at 3:55 AM, At Work <[email protected]> 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, [email protected] <[email protected]
>
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
[email protected]
http://lists.nongnu.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/gluster-devel
