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 picture. 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. Chris -----Original Message----- From: Martin Fick [mailto:mogulguy@xxxxxxxxx] Sent: Tuesday, March 25, 2008 1:08 PM To: Christopher Hawkins; gluster-devel@xxxxxxxxxx Subject: Re: Unify without AFR --- Christopher Hawkins <chawkins@xxxxxxxxxxxxxxxxxxxx> 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! -Martin
