> I tried to write to support@xxxxxxxxxxxxx and got a note that the message
> was waiting for moderator approval but never got anything beyond that.
sorry for that, a spike in spam content made us change it to a
moderated ID, will look into it right away.
> Where I work we are interested in Gluster but we are a FreeBSD shop.
> We would like to see FreeBSD support in the roadmap.
supporting both GlusterHPC and GlusterFS is surely one of our tasks,
though we do not have a committed timeline for them yet.
> Also we would like to know if there is , or will be commercial support for
> the product.
I suppose it's too early to ask for commercial support yet (given that the
first code checkin happened less than 9 months ago)... but nobody will stop
you to ask for it :-)
Z RESEARCH is already providing commercial support for glusterfs in a
few locations across the globe. We prefer to keep this list a pure
technical discussion list and have support requests come to
support@xxxxxxxxxxxxx
Talking about requests: I re-read my bunch of printouts last weekend, and
have some suggestions as well (Avati, are you there?):
- to have the servers know about each other helps to avoid - or properly
handle - split-brain situations. One might imagine networks with
multiple core switches - if the interconnect between them breaks,
bad things may happen.
this change is being brought in to AFR translator already where AFR
would work on the server side with knowledge of each other. this will
make it to the 1.3 release itself.
- in any case, and by any means, one should keep the config as symmetrical
as possible. so if a bunch of servers is configured for unify, afr
or the like, they should all use the same config (to avoid typos
in a single copy), and automagically detect that a reference to
a server can be resolved locally.
autofs is a good example for such behaviour: a NFS mount would
be replaced by a local bind mount.
this is what we too crave for, but thinks like IP addresses being
different not much can be done (when AFR is loaded on server side,
each node will have a seperate config file mentioning its mirrored
peers).
- the documentation of the translators (as of two weeks ago)needs some
restructuring - it's of little use only to know that the translators
are there (I can look into the xlator/ subdirectory if I want to know),
more important would be a thorough description of the possible options
(and trashcan is completely missing). I know, it's a Wiki, and I might
add stuff myself, but how can I if I don't know?
we are still working on the documentation, thanks for your pointers.
thanks,
avati
--
Anand V. Avati
