Many thanks for your response.
With regards to number 3, yes, I mean file locking (and byte-range locking
of a file if that's also supported). I just wanted to make sure that file
locks are handled properly for replicated data.
With regards to number 4, I just wanted to be certain that if you had
multiple storage targets on each of multiple nodes, that you can configure
it such that your replica of any data is always on another node, never on
the same node. Otherwise, if a node went down, of course, you'd lose
access to the data AND the replica.
Let me know what else you want to know (and if you have tried, GlusterFS
already, your feed back about the software). Finally its the users who gives
the shape to software.
That is a very cool aspect of the GlusterFS project. With its modular
design, all sorts of cool features are being coded at an amazingly rapid
rate. Very impressive.
Thanks,
Brent
On Fri, 16 Feb 2007, Amar S. Tumballi wrote:
Hi Brent,
The need of a simple, reliable cluster filesystem is fueling the GlusterFS
developpers :)
I will try to answer your questions one by one.
1) AFR will write the data simultaniously to all the nodes (in GlusterFS term,
on each of its child nodes). It won't store data till close (), or not even
any of the two glusterfsd servers talk to themself. (Our design is such that,
each server is independent of other servers). In case of one node failure, it
still writes to available nodes, but when the missing node comes up, the
'glusterfs-fsck' (in development phase) will take care of getting a replica
of all the missing files.
2) Yes, thats the idea. When we have the opportunity to make our read faster
by reading it in different chunks, we want to utilize that. But with this
release, we are not yet having it. :|
3) you mean file locking (fnctl?) ? (because in clustered filesystem, we have
locking of namespace too)
4) Can you elaborate more on your question?
For your general question, answer would be yes :) (as we have very flexible
configuration, we can cover your needs).
Let me know what else you want to know (and if you have tried, GlusterFS
already, your feed back about the software). Finally its the users who gives
the shape to software.
Regards,
-bulde (on #gluster - irc.gnu.org)
On Fri, Feb 16, 2007 at 03:24:56PM -0500, Brent A Nelson wrote:
I see that the AFR automatic replication module is now listed as complete
and scheduled for the February 20th 1.4 release. While we are eagerly
awaiting it, is there any documentation somewhere about how it operates?
It sounds like this will provide an easily installed and configured, truly
redundant (no single points of failure) high-performance distributed
filesystem, without having to resort to extra layers (such as drbd). In
otherwords, filesystem nirvana. ;-)
Some some-what specific questions:
1) When does replication take place? When a client is writing to a file,
does it write to two (or more) servers at the same time, or does one server
replicate the file to the other server after close, or...? If a replica
server goes down, how does it catch up with changes since it was down? Do
the clients know to use the good replica server while the other server is
catching up?
2) Assuming replicas are in sync, will clients load-balance reads across
the multiple replicas for increased performance? What about writes?
3) How are locks handled between replicas?
4) GlusterFS looks to be extremely flexible with regards to its
configuration, but I just want to be sure: if AFR is working with multiple
nodes, each containing multiple disks as part of a filesystem, will we be
able to guarantee that replicas will be stored on different nodes (i.e., so
a node can fail and the data will still be fully available).
A completely vague, general question:
I'd like to run standard departmental services across one or more
redundant, distributed filesystems. This would include home directories
and data directories, as well as directories that would be shared amongst
multiple servers for the express purpose of running redundant (and
load-leveled, when possible) services (mail, web, load-leveled NFS export
for any systems that can't mount the filesystem directly, hopefully
load-leveled SAMBA, etc.). Would GlusterFS (with AFR) be a good match?
I've been working with Lustre+DRBD+Heartbeat, and it seems like it will
work, but the complexity of it makes me nervous (it may be fragile, and
prone to breakage with future updates, especially with its strong
dependence still upon numerous kernel patches that differ by kernel
release). GlusterFS sounds much simpler (thanks to its modularity) and is
about to get built-in replication...
Thanks,
Brent Nelson
Director of Computing
Dept. of Physics
University of Florida
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel
