[Gluster-users] Painfully slow volume actions

[Anand Avati]

Is it possible that each of your bricks is in its own vm, and the vm system
drives (where /var/lib/glusterd resides) are all placed on the same host
drive? Glusterd updates happen synchronously even in the latest release and
the change to use buffered writes + fsync went into master only recently..
 On May 21, 2014 1:25 AM, "Benjamin Kingston" <list at nexusnebula.net> wrote:

> I'm trying to get gluster working on a test lab and had excellent success
> setting up a volume and 14 bricks on the first go around. However I
> realized the reasoning behind using a subdirectory in each brick and
> decommissioned the whole volume to start over. I also deleted the
> /var/lib/glusterd directory and removed/installed the necessary gluster
> packages. I'm running Scientific linux 6.4 with all recent updates.
>
> Upon recreating the new volume with the new brick, I found the process
> very very slow, about 2-3 minutes to process the change. Adding additional
> bricks also takes the same amount of time as well as simple set parameter
> actions. This was with a distributed volume with only one host involved.
>
> I notice in the cli log file, it constantly complains about not being able
> to guess the transport family, which an online search for the error or
> parts of the error only brought up issues that apply to older versions of
> gluster.
>
> One thing of note, is I'm currently trying a distributed volume with a 2nd
> host, and actions are still slow on the host containing the batch of bricks
> I'm trying to add is very slow, however the other host with no volumes at
> this time runs gluster vol info volname very quickly. I will be trying to
> add bricks shortly, but since I had very quick response the first time
> around I'm hoping someone may be able to shed some light for me.
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140521/cdf4e0ad/attachment.html>