GlusterFS doesn't have an automated repair (resync if node goes down),
yet. However, an rsync should do the trick until they have their
"self-healing" in place. The roadmap shows the self-healing feature as
the next release, although it also shows that the release should have
already happened. ;-)
Does anyone have a guesstimate as to when self-heal (or at least a roadmap
update) might appear?
Thanks,
Brent
PS I just noticed the client-side inode item on the roadmap; that should
fix the KDE problem mentioned on the list a few messages ago, as well as
allow hardlinks, correct?
On Wed, 4 Apr 2007, Gerry Reno wrote:
Yes, I think it is DRBD 0.8 that has this where you can mount both sides
simultaneously. We are only using DRBD 0.7 right now and I'm looking to see
if GlusterFS may be a more capable solution for us. Looking for better
scalability. I've never had to work with the underlying devices in DRBD.
Worse case I just forced a full sync. And I'm hoping that is the case with
GlusterFS.
Gerry
Brent A Nelson wrote:
You can work with the underlying filesystem, say, to fix a problem, but
you'd want to work with it the way GlusterFS would, at least for
consistency. So, if it's a mirror, any change you make on one, you'd want
to reproduce on the other.
With drbd, you could only have one mounted at any given time; otherwise,
even mounting the other one would be something of a catastrophe. Note that
this isn't true of recent, bidirectional drbds, if you run GFS.
Thanks,
Brent
On Wed, 4 Apr 2007, Gerry Reno wrote:
Avati,
Yes, of course, it works. So it is similar to DRBD where you must only
interact via the exposed mounts and never directly to the underlying
subsystem.
Gerry
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxx
http://lists.nongnu.org/mailman/listinfo/gluster-devel
