Re: [Gluster-users] glusterfs under high load failing?

2014-10-14 Thread Roman
Oh, I'm really sorry!

Its debian wheezy with gluster repo on it.

root@stor1:~# gluster --version
glusterfs 3.5.2 built on Sep  3 2014 03:08:33
Repository revision: git://git.gluster.com/glusterfs.git
Copyright (c) 2006-2011 Gluster Inc. 
GlusterFS comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GlusterFS under the terms of the GNU General
Public License.


2014-10-15 0:27 GMT+03:00 Justin Clift :

> - Original Message -
> > Hi,
> >
> > I've got this kind of setup (servers run replica)
>
> As a thought, just because the info doesn't seem to be in the
> posts so far... which version(s) of GlusterFS are you using,
> and on which OS's?
>
> Just in case you're not using the latest release(s), and this
> is a known bug thing. :)
>
> Regards and best wishes,
>
> Justin Clift
>
> --
> GlusterFS - http://www.gluster.org
>
> An open source, distributed file system scaling to several
> petabytes, and handling thousands of clients.
>
> My personal twitter: twitter.com/realjustinclift
>



-- 
Best regards,
Roman.
___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] FailOver

2014-10-14 Thread Punit Dambiwal
Hi All,

Is there any body can help me ???

On Mon, Oct 13, 2014 at 11:54 AM, Punit Dambiwal  wrote:

> Hi,
>
> I have one question regarding the gluster failover...let me explain my
> current architecture,i am using Ovirt with gluster...
>
> 1. One Ovirt Engine (Ovirt 3.4)
> 2. 4 * Ovirt Node as well as Gluster storage node...with 12 brick in one
> node...(Gluster Version 3.5)
> 3. All 4 node in distributed replicated structure with replica level =2...
> 4. I have one spare node with 12 brick for Failover purpose..
>
> Now there is two questions :-
>
> 1. If any of brick failed...how i can failover this brick...how to remove
> the failed brick and replace with another brick?? Do i need to replace
> the whole node or i can replace the single brick ??
>
> 2. If one of the whole node with 12 brick down and can not come up...how i
> can replace it with the new onedo i need to add two node to main the
> replication level... ??
>
> Thanks,
> Punit
>
___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] glusterfs under high load failing?

2014-10-14 Thread Justin Clift
- Original Message -
> Hi,
> 
> I've got this kind of setup (servers run replica)

As a thought, just because the info doesn't seem to be in the
posts so far... which version(s) of GlusterFS are you using,
and on which OS's?

Just in case you're not using the latest release(s), and this
is a known bug thing. :)

Regards and best wishes,

Justin Clift

-- 
GlusterFS - http://www.gluster.org

An open source, distributed file system scaling to several
petabytes, and handling thousands of clients.

My personal twitter: twitter.com/realjustinclift
___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users


Re: [Gluster-users] Re-Sync Geo Replication

2014-10-14 Thread James Payne
I can confirm that using touch works and the file is resync'd

Thanks for your help :)

James

--- Original Message ---

From: "Venky Shankar" 
Sent: 8 October 2014 12:41
To: "James Payne" 
Cc: "gluster-users" 
Subject: Re: [Gluster-users] Re-Sync Geo Replication

​"touch " should trigger a re-sync.

On Sun, Oct 5, 2014 at 3:03 AM, James Payne  wrote:

> Hi,
>
>
>
> Just wondering if there was a method to manually force a re-sync of a geo
> replication slave so it is an identical mirror of the master?
>
>
>
> History of this request is that I have a test setup and the Gluster
> Geo-Replication seems to have missed 7 files out completely (not sure if
> this was a bug or an issue with my setup specifically as this is a test
> setup it has been setup and torn down a few times). Now though the Geo
> replica will not converge to be the same, ie. It’s stable, new files add
> fine and files will delete, but the missing files just don’t seem to be
> interested in synchronising! I’m guessing that as the rsync is triggered by
> the change log and as these files aren’t changing it won’t ever notice them
> again? I can manually copy the files (there are only 7 after all…) but I
> have only found them through a consistency checking script I wrote. I can
> run this through a cron to pick up any missing files, however I wondered if
> Gluster had something built in which did a check and sync? Also, If I did
> manually copy these files across how would that affect the consistency of
> the geo replica session?
>
>
>
> Running: GlusterFS 3.4.5 on CentOS 6.5
>
>
>
> Regards
>
> James
>
>
>
> ___
> Gluster-users mailing list
> Gluster-users@gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>
___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users

Re: [Gluster-users] replaceing bricks from a cluster with replication

2014-10-14 Thread Joe Julian

Start with:
  gluster volume replace-brick myvol1 machine1:/foo machineA:/foo 
commit force


Then do:
  gluster volume heal myvol1 info
until it's empty which should indicate that the new brick on machineA 
now has a complete replica.


repeat above for machine2/B and machine3/C.

On 10/09/2014 01:30 PM, John G. Heim wrote:
How can I replace machines in a gluster cluster with triple 
replication? I've had crashes and I've replaces single machines before 
but always with one with the same name. Now I need to take machine1, 
machine2, and machine3 out of the cluster and replace it with 
machineA, machineB, and machineC.


Gluster will not let me detach machine1 all by itself. I have to detach
 machine1, machine2, and machine3 all at the same time. But is that 
going to cause data loss?


It seems to me that detaching all 3 machines in a brick on a triple 
replicated cluster would be like removing a single brick from a 
non-replicated cluster. And you can lose data in that case, right?

___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users


___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users


Re: [Gluster-users] geo-replication breaks on CentOS 6.5 + gluster 3.6.0 beta3

2014-10-14 Thread James Payne
Just adding that I have verified this as well with the 3.6 beta, I added a
log to the ticket regarding this. 

https://bugzilla.redhat.com/show_bug.cgi?id=1141379

Please feel free to add to the bug report, I think we are seeing the same
issue. It isn't present in the 3.4 series which in the one I'm testing
currently. (no distributed geo rep though)

Regards
James

-Original Message-
From: Kingsley [mailto:glus...@gluster.dogwind.com] 
Sent: 13 October 2014 16:51
To: gluster-users@gluster.org
Subject: [Gluster-users] geo-replication breaks on CentOS 6.5 + gluster
3.6.0 beta3

Hi,

I have a small script to simulate file activity for an application we have.
It breaks geo-replication within about 15 - 20 seconds when I try it.

This is on a small Gluster test environment running in some VMs running
CentOS 6.5 and using gluster 3.6.0 beta3. I have 6 VMs - test1, test2,
test3, test4, test5 and test6. test1, test2 , test3 and test4 are gluster
servers while test5 and test6 are the clients. test3 is actually not used in
this test.


Before the test, I had a single gluster volume as follows:

test1# gluster volume status
Status of volume: gv0
Gluster process PortOnline  Pid

--
Brick test1:/data/brick/gv0 49168   Y
12017
Brick test2:/data/brick/gv0 49168   Y
11835
NFS Server on localhost 2049Y
12032
Self-heal Daemon on localhost   N/A Y
12039
NFS Server on test4 2049Y   7934
Self-heal Daemon on test4   N/A Y   7939
NFS Server on test3 2049Y
11768
Self-heal Daemon on test3   N/A Y
11775
NFS Server on test2 2049Y
11849
Self-heal Daemon on test2   N/A Y
11855

Task Status of Volume gv0

--
There are no active volume tasks


I created a new volume and set up geo-replication as follows (as these are
test machines I only have one file system on each, hence using "force" to
create the bricks in the root FS):

test4# date ; gluster volume create gv0-slave test4:/data/brick/gv0-slave
force; date Mon Oct 13 15:03:14 BST 2014 volume create: gv0-slave: success:
please start the volume to access data Mon Oct 13 15:03:15 BST 2014

test4# date ; gluster volume start gv0-slave; date Mon Oct 13 15:03:36 BST
2014 volume start: gv0-slave: success Mon Oct 13 15:03:39 BST 2014

test4# date ; gluster volume geo-replication gv0 test4::gv0-slave create
push-pem force ; date Mon Oct 13 15:05:59 BST 2014 Creating geo-replication
session between gv0 & test4::gv0-slave has been successful Mon Oct 13
15:06:11 BST 2014


I then mount volume gv0 on one of the client machines. I can create files
within the gv0 volume and can see the changes being replicated to the
gv0-slave volume, so I know that geo-replication is working at the start.

When I run my script (which quickly creates, deletes and renames files),
geo-replication breaks within a very short time. The test script output is
in http://gluster.dogwind.com/files/georep20141013/test6_script-output.log
(I interrupted the script once I saw that geo-replication was broken).
Note that when it deletes a file, it renames any later-numbered file so that
the file numbering remains sequential with no gaps; this simulates a real
world application that we use.

If you want a copy of the test script, it's here:
http://gluster.dogwind.com/files/georep20141013/test_script.tar.gz


The various gluster log files can be downloaded from here:
http://gluster.dogwind.com/files/georep20141013/ - each log file has the
actual log file path at the top of the file.

If you want to run the test script on your own system, edit test.pl so that
@mailstores contains a directory path to a gluster volume.

My systems' timezone is BST (GMT+1 / UTC+1) so any timestamps outside of
gluster logs are in this timezone.

Let me know if you need any more info.

--
Cheers,
Kingsley.



___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users


Re: [Gluster-users] replaceing bricks from a cluster with replication

2014-10-14 Thread Ted Miller


On 10/9/2014 4:30 PM, John G. Heim wrote:
How can I replace machines in a gluster cluster with triple replication? 
I've had crashes and I've replaces single machines before but always with 
one with the same name. Now I need to take machine1, machine2, and machine3 
out of the cluster and replace it with machineA, machineB, and machineC.


Gluster will not let me detach machine1 all by itself. I have to detach
 machine1, machine2, and machine3 all at the same time. But is that going 
to cause data loss?


It seems to me that detaching all 3 machines in a brick on a triple 
replicated cluster would be like removing a single brick from a 
non-replicated cluster. And you can lose data in that case, right? 
I am just a user with a replica = 3 cluster running, but I will try to 
outline how I would to it.  If I goof something up (or explain it badly) I 
hope that others will jump in and correct me.


You don't say, so I will assume you have 2 bricks per machine, resulting in 2 
names returned when you execute a


gluster volume list

command.  I will assume that your volumes are named 'Dick' and 'Jane'.

The only way I know how to do what you want to do is a rather tedious 
process, but here it is.  I will not try to get all the commands word 
perfect, more like give you "pseudocode".


The basic premise is that you cannot add "machines", you can only add and 
subtract bricks from a volume.


1. Add machineA to the cluster as a peer.
2. Add brick "DickA" on machineA to volume "Dick", resulting in a "replica 4" 
volume.
3. Remove brick "Dick1" on machine1 from volume "Dick", putting you back at a 
"replica 3" volume.

4. Repeat steps 2 & 3 for "JaneA" and "Jane1".
5. At this point you no longer have any data on machine1, so remove machine1 
from the cluster.


Repeat steps 1-5, substituting machineB and machine2.

Repeat steps 1-5, substituting machineC and machine3.

At that point you should be migrated from machine1,2,3  to machineA,B,C.

Is that clear as mud?

It is probably more tedious than what you wanted to do (especially if you 
have 5 or more volumes), but it is the only way I know to do it.


Have fun,
Ted Miller
Elkhart, IN, USA

___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users


Re: [Gluster-users] RHEL6.6 provides Gluster 3.6.0-28.2 ?

2014-10-14 Thread Chad Feller

I was hit by this too this morning:

What you can do is install the "yum-plugin-priorities" package, and then 
add a weight to (say, "priority=50") to each section of your 
glusterfs.repo file.  That will weight the community glusterfs packages 
higher, causing yum to ignore the newer version available via rhn.


If you're using a configuration management tool like puppet, pushing out 
this workaround is to all your servers incredibly simple and should take 
but a couple minutes.


-Chad


On 10/14/2014 09:56 AM, daryl herzmann wrote:

Howdy,

I'm getting RPM conflicts as the RHEL6.6 update attempts to update 
gluster client RPMs, but the latest release from gluster.org is 3.5.2 ?


Am I missing something obvious here?  Seems strange for RHEL to 
include a version that isn't available upstream yet :)


https://bugzilla.redhat.com/show_bug.cgi?id=1095604

Is there a suggested workaround to this or simply wait for upstream to 
release a newer 3.6.0 ?  I have `yum  update --skip-broken` for now...


thanks,
  daryl

Error: Package: glusterfs-server-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   Requires: glusterfs = 3.5.2-1.el6
   Removing: glusterfs-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   glusterfs = 3.5.2-1.el6
   Updated By: glusterfs-3.6.0.29-2.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs = 3.6.0.29-2.el6
   Available: glusterfs-3.4.0.36rhs-1.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs = 3.4.0.36rhs-1.el6
   Available: glusterfs-3.4.0.57rhs-1.el6_5.x86_64 
(rhel-x86_64-server-6)

   glusterfs = 3.4.0.57rhs-1.el6_5
   Available: glusterfs-3.6.0.28-2.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs = 3.6.0.28-2.el6
Error: Package: glusterfs-server-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   Requires: glusterfs-cli = 3.5.2-1.el6
   Removing: glusterfs-cli-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   glusterfs-cli = 3.5.2-1.el6
   Updated By: glusterfs-cli-3.6.0.29-2.el6.x86_64 
(rhel-x86_64-server-optional-6)

   glusterfs-cli = 3.6.0.29-2.el6
   Available: glusterfs-cli-3.6.0.28-2.el6.x86_64 
(rhel-x86_64-server-optional-6)

   glusterfs-cli = 3.6.0.28-2.el6
Error: Package: glusterfs-server-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   Requires: glusterfs-fuse = 3.5.2-1.el6
   Removing: glusterfs-fuse-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   glusterfs-fuse = 3.5.2-1.el6
   Updated By: glusterfs-fuse-3.6.0.29-2.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs-fuse = 3.6.0.29-2.el6
   Available: glusterfs-fuse-3.4.0.36rhs-1.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs-fuse = 3.4.0.36rhs-1.el6
   Available: glusterfs-fuse-3.4.0.57rhs-1.el6_5.x86_64 
(rhel-x86_64-server-6)

   glusterfs-fuse = 3.4.0.57rhs-1.el6_5
   Available: glusterfs-fuse-3.6.0.28-2.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs-fuse = 3.6.0.28-2.el6
Error: Package: glusterfs-server-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   Requires: glusterfs-libs = 3.5.2-1.el6
   Removing: glusterfs-libs-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   glusterfs-libs = 3.5.2-1.el6
   Updated By: glusterfs-libs-3.6.0.29-2.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs-libs = 3.6.0.29-2.el6
   Available: glusterfs-libs-3.4.0.36rhs-1.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs-libs = 3.4.0.36rhs-1.el6
   Available: glusterfs-libs-3.4.0.57rhs-1.el6_5.x86_64 
(rhel-x86_64-server-6)

   glusterfs-libs = 3.4.0.57rhs-1.el6_5
   Available: glusterfs-libs-3.6.0.28-2.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs-libs = 3.6.0.28-2.el6

___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users


___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users


[Gluster-users] RHEL6.6 provides Gluster 3.6.0-28.2 ?

2014-10-14 Thread daryl herzmann

Howdy,

I'm getting RPM conflicts as the RHEL6.6 update attempts to update gluster 
client RPMs, but the latest release from gluster.org is 3.5.2 ?


Am I missing something obvious here?  Seems strange for RHEL to include a 
version that isn't available upstream yet :)


https://bugzilla.redhat.com/show_bug.cgi?id=1095604

Is there a suggested workaround to this or simply wait for upstream to 
release a newer 3.6.0 ?  I have `yum  update --skip-broken` for now...


thanks,
  daryl

Error: Package: glusterfs-server-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   Requires: glusterfs = 3.5.2-1.el6
   Removing: glusterfs-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   glusterfs = 3.5.2-1.el6
   Updated By: glusterfs-3.6.0.29-2.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs = 3.6.0.29-2.el6
   Available: glusterfs-3.4.0.36rhs-1.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs = 3.4.0.36rhs-1.el6
   Available: glusterfs-3.4.0.57rhs-1.el6_5.x86_64 
(rhel-x86_64-server-6)

   glusterfs = 3.4.0.57rhs-1.el6_5
   Available: glusterfs-3.6.0.28-2.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs = 3.6.0.28-2.el6
Error: Package: glusterfs-server-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   Requires: glusterfs-cli = 3.5.2-1.el6
   Removing: glusterfs-cli-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   glusterfs-cli = 3.5.2-1.el6
   Updated By: glusterfs-cli-3.6.0.29-2.el6.x86_64 
(rhel-x86_64-server-optional-6)

   glusterfs-cli = 3.6.0.29-2.el6
   Available: glusterfs-cli-3.6.0.28-2.el6.x86_64 
(rhel-x86_64-server-optional-6)

   glusterfs-cli = 3.6.0.28-2.el6
Error: Package: glusterfs-server-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   Requires: glusterfs-fuse = 3.5.2-1.el6
   Removing: glusterfs-fuse-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   glusterfs-fuse = 3.5.2-1.el6
   Updated By: glusterfs-fuse-3.6.0.29-2.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs-fuse = 3.6.0.29-2.el6
   Available: glusterfs-fuse-3.4.0.36rhs-1.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs-fuse = 3.4.0.36rhs-1.el6
   Available: glusterfs-fuse-3.4.0.57rhs-1.el6_5.x86_64 
(rhel-x86_64-server-6)

   glusterfs-fuse = 3.4.0.57rhs-1.el6_5
   Available: glusterfs-fuse-3.6.0.28-2.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs-fuse = 3.6.0.28-2.el6
Error: Package: glusterfs-server-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   Requires: glusterfs-libs = 3.5.2-1.el6
   Removing: glusterfs-libs-3.5.2-1.el6.x86_64 (@glusterfs-epel)
   glusterfs-libs = 3.5.2-1.el6
   Updated By: glusterfs-libs-3.6.0.29-2.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs-libs = 3.6.0.29-2.el6
   Available: glusterfs-libs-3.4.0.36rhs-1.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs-libs = 3.4.0.36rhs-1.el6
   Available: glusterfs-libs-3.4.0.57rhs-1.el6_5.x86_64 
(rhel-x86_64-server-6)

   glusterfs-libs = 3.4.0.57rhs-1.el6_5
   Available: glusterfs-libs-3.6.0.28-2.el6.x86_64 
(rhel-x86_64-server-6)

   glusterfs-libs = 3.6.0.28-2.el6

___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users


Re: [Gluster-users] Upcoming Bug Prioritization meeting Tuesday, 14-Oct (meeting minutes)

2014-10-14 Thread Niels de Vos
On Mon, Oct 13, 2014 at 10:07:51AM -0700, Dave McAllister wrote:
> Good day, all
> 
> Just a reminder that we will be having a GlusterFS bug prioritization
> meeting Tuesday 14-Oct-2014, 12:00 UTC.
> 
> More information available at : 
> http://blog.gluster.org/2014/10/whats-that-bug-to-you-glusterfs-bug-priority-meeting/

Due to some IRC instability from my side, the topics are missing in the
meeting summary. If you are interested in the details, it may be easier
and quicker to read through the chat log:
- 
http://meetbot.fedoraproject.org/gluster-meeting/2014-10-14/gluster-meeting.2014-10-14-12.02.log.html

Some of the usual attendees were missing, so we skipped through many of
the follow-up items. The following action items were added today:

- hchiramm_ should be online when his topics get discussed (ndevos_, 12:12:46)
- ndevos will send an email about FutureFeature/[FEAT] marking of feature 
requests to the -devel list (ndevos_, 12:30:33)
- ndevos_ will update the feature template to include a link to the bug for the 
feature (ndevos_, 12:32:06)
- ndevos will add a note about the Patch keyword for backports in the Bug 
Triage Guidelines (ndevos_, 12:54:11)
- ndevos will add a note about the Patch keyword for backports in the "How to 
clone" wiki page (ndevos_, 12:55:50)
- jdarcy will try the RSS-feeds and will report next week (ndevos_, 13:01:32)

We'll do an other session next week, same place, same time. Don't be afraid to
attend!

Cheers,
Niels
___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users


Re: [Gluster-users] geo-replication breaks on CentOS 6.5 + gluster 3.6.0 beta3

2014-10-14 Thread Kingsley
It's worth me adding that since geo-replication broke, if I query the
volume status (in this instance, on test1), I get this:

test1# gluster volume status
Another transaction is in progress. Please try again after sometime.

It's still giving this error, 24 hours later.

Cheers,
Kingsley.

On Mon, 2014-10-13 at 16:51 +0100, Kingsley wrote:
> Hi,
> 
> I have a small script to simulate file activity for an application we
> have. It breaks geo-replication within about 15 - 20 seconds when I try
> it.
> 
> This is on a small Gluster test environment running in some VMs running
> CentOS 6.5 and using gluster 3.6.0 beta3. I have 6 VMs - test1, test2,
> test3, test4, test5 and test6. test1, test2 , test3 and test4 are
> gluster servers while test5 and test6 are the clients. test3 is actually
> not used in this test.
> 
> 
> Before the test, I had a single gluster volume as follows:
> 
> test1# gluster volume status
> Status of volume: gv0
> Gluster process PortOnline  Pid
> --
> Brick test1:/data/brick/gv0 49168   Y   12017
> Brick test2:/data/brick/gv0 49168   Y   11835
> NFS Server on localhost 2049Y   12032
> Self-heal Daemon on localhost   N/A Y   12039
> NFS Server on test4 2049Y   7934
> Self-heal Daemon on test4   N/A Y   7939
> NFS Server on test3 2049Y   11768
> Self-heal Daemon on test3   N/A Y   11775
> NFS Server on test2 2049Y   11849
> Self-heal Daemon on test2   N/A Y   11855
> 
> Task Status of Volume gv0
> --
> There are no active volume tasks
> 
> 
> I created a new volume and set up geo-replication as follows (as these
> are test machines I only have one file system on each, hence using
> "force" to create the bricks in the root FS):
> 
> test4# date ; gluster volume create gv0-slave test4:/data/brick/gv0-slave 
> force; date
> Mon Oct 13 15:03:14 BST 2014
> volume create: gv0-slave: success: please start the volume to access data
> Mon Oct 13 15:03:15 BST 2014
> 
> test4# date ; gluster volume start gv0-slave; date
> Mon Oct 13 15:03:36 BST 2014
> volume start: gv0-slave: success
> Mon Oct 13 15:03:39 BST 2014
> 
> test4# date ; gluster volume geo-replication gv0 test4::gv0-slave create 
> push-pem force ; date
> Mon Oct 13 15:05:59 BST 2014
> Creating geo-replication session between gv0 & test4::gv0-slave has been 
> successful
> Mon Oct 13 15:06:11 BST 2014
> 
> 
> I then mount volume gv0 on one of the client machines. I can create
> files within the gv0 volume and can see the changes being replicated to
> the gv0-slave volume, so I know that geo-replication is working at the
> start.
> 
> When I run my script (which quickly creates, deletes and renames files),
> geo-replication breaks within a very short time. The test script output
> is in
> http://gluster.dogwind.com/files/georep20141013/test6_script-output.log
> (I interrupted the script once I saw that geo-replication was broken).
> Note that when it deletes a file, it renames any later-numbered file so
> that the file numbering remains sequential with no gaps; this simulates
> a real world application that we use.
> 
> If you want a copy of the test script, it's here:
> http://gluster.dogwind.com/files/georep20141013/test_script.tar.gz
> 
> 
> The various gluster log files can be downloaded from here:
> http://gluster.dogwind.com/files/georep20141013/ - each log file has the
> actual log file path at the top of the file.
> 
> If you want to run the test script on your own system, edit test.pl so
> that @mailstores contains a directory path to a gluster volume.
> 
> My systems' timezone is BST (GMT+1 / UTC+1) so any timestamps outside of
> gluster logs are in this timezone.
> 
> Let me know if you need any more info.
> 

___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users


Re: [Gluster-users] Compiling on Solaris 11

2014-10-14 Thread Benjamin Kingston
So I was able to compile gluster 3.3.2. on Solaris 11 and have it running a
volume now! Which is great, I couldn't be more excited.

What this brings to mind, however, is I am missing out on the newer
features and management commands I was used to in version 3.4, when I
started with gluster, and why recent glusters need contrib/mount/mntent.c
(which mentions Darwin, BSD, and Linux, but not Solaris)

Here's the make and configure commands I used to build 3.3.2. sucessfully,
however don't work on 3.4 or above

./autogen.sh
gmake distclean
LDFLAGS="-L/opt/csw/lib" CC=/usr/gcc/4.8/bin/gcc CPP=/usr/gcc/4.8/bin/cpp
CFLAGS="-m64" ./configure --disable-crypt-xlator --disable-qemu-block
--disable-fusermount --disable-systemtap --disable-ibverbs
--disable-fuse-client --prefix=/opt/glusterfs;
gmake;

I also had to edit nlm4-xdr.h to change the u_init32 and u_init64 to
uinit32 and uinit64 to resolve a type unknown compile error.

One edit I would like some feedback on because it throws a warning instead
of failing before the edit is in posix.c. I don't know any programming so
this is pulled from stack overflow and applied as best I can. Any proof
reading before I consider this complete would be greatly appreciated.

The error:
In file included from ../../../../libglusterfs/src/xlator.h:61:0,
 from posix.h:50,
 from posix.c:49:
posix.c: In function ‘posix_fill_readdir’:
posix.c:3628:44: error: ‘struct dirent’ has no member named ‘d_type’
 if (DT_ISDIR (entry->d_type)) {
^
the edit:

[BEFORE]
if (skip_dirs) {
if (DT_ISDIR (entry->d_type)) {
continue;
} else if (hpath) {
strcpy (&hpath[len+1],entry->d_name);
ret = lstat (hpath, &stbuf);
if (!ret && S_ISDIR (stbuf.st_mode))
continue;
}
}

[AFTER]
if (skip_dirs) {
struct stat s;
stat(entry->d_name, &s);
if (DT_ISDIR ((s.st_mode & S_IFDIR))) {
continue;
} else if (hpath) {
strcpy (&hpath[len+1],entry->d_name);
ret = lstat (hpath, &stbuf);
if (!ret && S_ISDIR (stbuf.st_mode))
continue;
}
}
/d_


On Sun, Oct 12, 2014 at 11:56 AM, Benjamin Kingston 
wrote:

> I fixed that particular issue as ucred.h was in /usr/include not
> /usr/include/sys so I made a symlink, unfortunately now I'm getting a new
> issue here:
>
> ../../contrib/mount/mntent.c: In function `statfs_to_mntent':
> ../../contrib/mount/mntent.c:129:36: error: dereferencing pointer to
> incomplete type
>  _mntent.mnt_fsname = mntbuf->f_mntfromname;
> ^
> ../../contrib/mount/mntent.c:130:33: error: dereferencing pointer to
> incomplete type
>  _mntent.mnt_dir = mntbuf->f_mntonname;
>  ^
> ../../contrib/mount/mntent.c:131:34: error: dereferencing pointer to
> incomplete type
>  _mntent.mnt_type = mntbuf->f_fstypename;
>   ^
> ../../contrib/mount/mntent.c:136:25: error: dereferencing pointer to
> incomplete type
>  f_flags = mntbuf->f_flags;
>  ^
> ../../contrib/mount/mntent.c: In function `getmntent':
> ../../contrib/mount/mntent.c:160:17: warning: implicit declaration of
> function `getmntinfo' [-Wimplicit-function-declaration]
>  mntsize = getmntinfo (&mntbuf, MNT_NOWAIT);
>  ^
> ../../contrib/mount/mntent.c:160:48: error: `MNT_NOWAIT' undeclared (first
> use in this function)
>  mntsize = getmntinfo (&mntbuf, MNT_NOWAIT);
> ^
> ../../contrib/mount/mntent.c:168:9: error: invalid use of undefined type
> `struct statfs'
>  return (statfs_to_mntent (&mntbuf[pos]));
>  ^
> ../../contrib/mount/mntent.c:168:42: error: dereferencing pointer to
> incomplete type
>  return (statfs_to_mntent (&mntbuf[pos]));
>   ^
> ../../contrib/mount/mntent.c:169:1: warning: control reaches end of
> non-void function [-Wreturn-type]
>  }
>  ^
>
> On Fri, Oct 10, 2014 at 8:48 PM, Benjamin Kingston 
> wrote:
>
>> I went back and build 3.6 and 3.7 with the build failing in the same
>> place when building libglusterfs
>>
>>
>> One thing I did find as different in the master build f5d544d
>> 
>> :
>>
>> ../../contrib/mount/mntent.c as I receive an error w

Re: [Gluster-users] Errors after updating to 3.5.2.1.el6

2014-10-14 Thread Jesus Carretero
Thanks!

When creating the volume, nothing is printed in mnt-.storage1.log:

# gluster volume create storage transport rdma julia:/mnt/.storage1
sandra:/mnt/.storage2 force
volume create: storage: success: please start the volume to access data

When trying to start it, this is what is printed:

# gluster volume start storage
volume start: storage: failed: Commit failed on localhost. Please
check the log file for more details.

mnt-.storage1.log:

[2014-10-14 07:33:02.824540] I [glusterfsd.c:1959:main]
0-/usr/sbin/glusterfsd: Started running /usr/sbin/glusterfsd version
3.5.2 (/usr/sbin/glusterfsd -s julia --volfile-id
storage.julia.mnt-.storage1 -p
/var/lib/glusterd/vols/storage/run/julia-mnt-.storage1.pid -S
/var/run/7eaed01afd14de7e3952eb902987f975.socket --brick-name
/mnt/.storage1 -l /var/log/glusterfs/bricks/mnt-.storage1.log
--xlator-option
*-posix.glusterd-uuid=4d50f191-88be-44ac-9a36-06b562e3e8e3
--brick-port 49159 --xlator-option storage-server.listen-port=49159)
[2014-10-14 07:33:02.828826] I [socket.c:3561:socket_init]
0-socket.glusterfsd: SSL support is NOT enabled
[2014-10-14 07:33:02.828886] I [socket.c:3576:socket_init]
0-socket.glusterfsd: using system polling thread
[2014-10-14 07:33:02.829086] I [socket.c:3561:socket_init]
0-glusterfs: SSL support is NOT enabled
[2014-10-14 07:33:02.829109] I [socket.c:3576:socket_init]
0-glusterfs: using system polling thread
[2014-10-14 07:33:02.843382] I [graph.c:254:gf_add_cmdline_options]
0-storage-server: adding option 'listen-port' for volume
'storage-server' with value '49159'
[2014-10-14 07:33:02.843414] I [graph.c:254:gf_add_cmdline_options]
0-storage-posix: adding option 'glusterd-uuid' for volume
'storage-posix' with value '4d50f191-88be-44ac-9a36-06b562e3e8e3'
[2014-10-14 07:33:02.844500] I
[rpcsvc.c:2127:rpcsvc_set_outstanding_rpc_limit] 0-rpc-service:
Configured rpc.outstanding-rpc-limit with value 64
[2014-10-14 07:33:02.845302] W [options.c:888:xl_opt_validate]
0-storage-server: option 'listen-port' is deprecated, preferred is
'transport.rdma.listen-port', continuing with correction
[2014-10-14 07:33:02.845950] W [rdma.c:4194:__gf_rdma_ctx_create]
0-rpc-transport/rdma: rdma_cm event channel creation failed (No such
device)
[2014-10-14 07:33:02.845978] E [rdma.c:4482:init]
0-rdma.storage-server: Failed to initialize IB Device
[2014-10-14 07:33:02.845991] E
[rpc-transport.c:333:rpc_transport_load] 0-rpc-transport: 'rdma'
initialization failed
[2014-10-14 07:33:02.846044] W [rpcsvc.c:1535:rpcsvc_transport_create]
0-rpc-service: cannot create listener, initing the transport failed
[2014-10-14 07:33:02.846065] W [server.c:912:init] 0-storage-server:
creation of listener failed
[2014-10-14 07:33:02.846078] E [xlator.c:403:xlator_init]
0-storage-server: Initialization of volume 'storage-server' failed,
review your volfile again
[2014-10-14 07:33:02.846093] E [graph.c:307:glusterfs_graph_init]
0-storage-server: initializing translator failed
[2014-10-14 07:33:02.846105] E [graph.c:502:glusterfs_graph_activate]
0-graph: init failed
[2014-10-14 07:33:02.846472] W [glusterfsd.c:1095:cleanup_and_exit]
(-->/usr/lib64/libgfrpc.so.0(rpc_clnt_handle_reply+0xa5)
[0x7f73d816f995] (-->/usr/sbin/glusterfsd(mgmt_getspec_cbk+0x320)
[0x40bd50] (-->/usr/sbin/glusterfsd(glusterfs_process_volfp+0x106)
[0x405146]))) 0-: received signum (0), shutting down

So it looks like there is a problem with rdma. Sandra and Julia
computers are successfully connected with Infiniband.



2014-10-13 18:21 GMT+02:00 Joe Julian :
>
> On 10/13/2014 09:07 AM, Jesus Carretero wrote:
>>
>> I updated my CentOS gluster to version 3.5.2.1.el6, and now the volume
>> doesn't start.
>>
>> This is the peer:
>>
>> # gluster peer status
>> Number of Peers: 1
>>
>> Hostname: sandra
>> Uuid: a6234622-a205-4311-8f60-8e30236fdd72
>> State: Peer in Cluster (Connected)
>>
>> This is the volume:
>>
>> # gluster volume create storage transport rdma julia:/mnt/.storage1
>> sandra:/mnt/.storage2 force
>> volume create: storage: success: please start the volume to access data
>>
>> # gluster volume info
>>
>> Volume Name: storage
>> Type: Distribute
>> Volume ID: 5ea2f8f5-c404-484b-b7b4-5a26fe66d6ac
>> Status: Created
>> Number of Bricks: 2
>> Transport-type: rdma
>> Bricks:
>> Brick1: julia:/mnt/.storage1
>> Brick2: sandra:/mnt/.storage2
>>
>> This is what happens when I try to start the storage:
>>
>> # gluster volume start storage
>> volume start: storage: failed: Commit failed on localhost. Please
>> check the log file for more details.
>>
>> This is the log /var/log/glusterfs/etc-glusterfs-glusterd.vol.log :
>>
>> [2014-10-13 16:02:17.084383] I
>> [glusterd-pmap.c:271:pmap_registry_remove] 0-pmap: removing brick
>> (null) on port 49158
>> [2014-10-13 16:02:17.091475] E
>> [glusterd-utils.c:4704:glusterd_brick_start] 0-management: Unable to
>> start brick julia:/mnt/.storage1
>> [2014-10-13 16:02:17.091523] E
>> [glusterd-syncop.c:1014:gd_commit_op_phase] 0-management: Commit of
>> operation 'Volume