[Gluster-users] Gluster performance

[Lone Wolf]

Kind of bizzare I have to agree, but as far as I can understand from the
docs geo-replication is one way, and I need two way because there can be
writes on both sides, rsync was an option but I would have to cron it and
each side at a time, and from my understanding could give me problems of
files either going missing or not being deleted.
Using the local for read is an option but since the files are being read and
written by the same application (apache) I see no way to split that.
What is more weird is that I managed to get it to read just one side for a
moment, after restarting gluster because of some adjustments, it started
reading both nodes again, even restoring config backups had no effect.

On Tue, Sep 27, 2011 at 1:37 PM, Whit Blauvelt <whit at transpect.com> wrote:

> Okay, what you're doing is a bizarre use of Gluster anyway. (They'd say you
> should use the "georeplication" instead - at which point a rsync run from
> cron will get you to about the same place without using Gluster at all.)
> But
> you can have local systems read from the backing store without corrupting
> the Gluster mirroring. Your writes all have to go through the Gluster
> mounts, but your reads don't.
>
> Whit
>
> On Tue, Sep 27, 2011 at 01:22:24PM +0100, Lone Wolf wrote:
> > Just checked it is mounted with noatime
> >
> > No dia 27 de Set de 2011 12:56, "Whit Blauvelt" <
> whit.gluster at transpect.com>
> > escreveu:
> > > On Tue, Sep 27, 2011 at 12:15:50PM +0100, Lone Wolf wrote:
> > >
> > >> So I am assuming gluster is distributing the reads, being created with
> the
> > >> CLI I tried to edit the configurations manually and added "option
> > >> read-subvolume volume_name" to the cluster/replicate volume, being the
> > >> read-subvolume the local one.
> > >
> > > Do you have your filesystems mounted "noatime"? If not, every read
> requires
> > > the atime (last access time) to be written to the files on both
> mirrors.
> > >
> > > Whit
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20110927/5d0c9bee/attachment.html>