[Gluster-devel] Unify without AFR
chawkins at veracitynetworks.com
Tue Mar 25 18:13:06 UTC 2008
Oops. Of course, you are correct. Glad I thought that through. ;-) I've
used both GFS and OCFS2 and would rather not introduce them into the
That being the case, perhaps there is no reason not to go with the AFR /
Unify examples in the documentation. I recall a lot of back and forth on the
mailing list re: timeouts when one server fails. If you set the timeout
somewhat low, like 5 seconds maybe, then an attempt to connect to a failed
server will time out at 5s and the node will try the next server in the
list, right? And is there a way to instruct that client not to continuously
attempt to connect to the failed server? That is what I was trying to avoid.
Can't find any specifics on this in the docs or tutorials. If you have a
server down for 24 hrs, say, has anyone found a good way to enable glusterfs
to deal with this?
I'm wondering now about using IP failover such that if a server went down,
the remaining server would take it's IP after a couple of seconds and
"pretend" to be that server for the clients. I don't think unify would care
because it's designed to present two identical filesystems as one namespace
anyway. AFR might get funky at that point because writing two copies of the
file would obviously not be necessary. Would this crash the gluster client,
if it went to write an AFR copy and it already existed? If the client is ok
with it, this might work.
From: Martin Fick [mailto:mogulguy at yahoo.com]
Sent: Tuesday, March 25, 2008 1:08 PM
To: Christopher Hawkins; gluster-devel at nongnu.org
Subject: Re: [Gluster-devel] Unify without AFR
--- Christopher Hawkins
<chawkins at veracitynetworks.com> wrote:
> What if I take two servers that export directory /example and use drbd
> v8 (which allows concurrent read / write) to mirror /example on server
> one to /example on server 2?
This isn't possible without a local filesystem that can handle concurrent
access like ocfs2 or glfs.
Remember, glusterfs works on top of the local filesystem. If you try this
with ext3 or another "normal" filesystem, you risk crashing the kernel
because it does not expect the filessytem to change from underneath itself!
More information about the Gluster-devel