On Tue, Aug 14, 2012 at 08:19:27PM -0700, stephen pierce wrote:
>I let both clients run for a while, then I stop one client. I then
>reset the brick/server that is not active (the other one is servicing
>the HTTP traffic) now.
Do you mean that client1 sends HTTP traffic to brick/server
I’ve been doing some failure testing, and I ran into a really nasty
condition. I'm hoping that I did something stupid. If you guys know what
happened, or can shed some light, please let me know.
My test environment is four virtual machines. Two I installed Gluster 3.3,
and created a redundant vo
On Tue, Aug 14, 2012 at 7:56 AM, Paolo Di Tommaso wrote:
> [2012-08-14 10:42:05.550471] E [socket.c:1715:socket_connect_finish]
> 0-glusterfs: connection to failed (No route to host)
>
ping uses icmp whereas the mount command uses TCP and they can use
different routing (as I was just taught by
On Wed, Aug 15, 2012 at 12:08 AM, Marcelo Roccasalva wrote:
> On Tue, Aug 14, 2012 at 7:06 PM, Paolo Di Tommaso
> wrote:
> >
> > Hi,
> >
> > I'm mounting using the following
> >
> > sudo mount -t glusterfs master:/vol1 /soft
>
> can you "ping master" from client?
>
Yes, it the first thing that
On Tue, Aug 14, 2012 at 7:06 PM, Paolo Di Tommaso
wrote:
>
> Hi,
>
> I'm mounting using the following
>
> sudo mount -t glusterfs master:/vol1 /soft
can you "ping master" from client?
> The command should be right since, it works in on the server node (master)
> but it is failing on a client.
>
Hi,
I'm mounting using the following
sudo mount -t glusterfs master:/vol1 /soft
The command should be right since, it works in on the server node (master)
but it is failing on a client.
Also I'm using the latests versions 3.3. (and it was working with the 3.2)
Best
Paolo
On Tue, Aug 14, 2
On Tue, Aug 14, 2012 at 04:56:17PM +0200, Paolo Di Tommaso wrote:
>The log reports the error (I've attached below the reported log
>file) : connection to failed (No route to host)
^^^
Missing hostname here. What exact command are you typing to try and mount?
Also
This should definitely be a bug report.
https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS
Thank you for bringing it to our attention. FWIW, it seems to me that
the nature of both the problem and the solution is quite clear, so we
should be able to start pushing it through th
On Tue, 14 Aug 2012 16:36:25 +0200 (CEST)
Jochen Klein wrote:
> So, at the moment a rebalance operation sets the same mapping
> intervals for all directories instead of shuffling them. Thus, it
> cannot achieve a proper distribution of the files, which I would
> consider a bug (at least I hope it'
Dear all,
I'm struggling mounting a Gluster shared volume.
I was able to create a simple volume with just one brick local to the
server node and mount it. But on the "client" node the mount if failing.
The log reports the error (I've attached below the reported log file)
: connection
to failed
Hi,
many thanks for the explanation. Then, there seems to be a problem with
the layout updating during rebalancing. For me all directories *do have*
the same mappings for the hash intervals, which creates this problem.
I checked another volume which had several bricks from the beginning, and
On 08/14/2012 03:44 AM, Jochen Klein wrote:
> Looking at the implementation in the dht translator and checking
> calculated hashes it seems that only the basename is used for the hash
> calculation of a given file. With all directories having the same
> mappings for the hash intervals to bricks, th
On Tue, Aug 14, 2012 at 12:19:10AM -0700, Joe Julian wrote:
>I'm betting that your bricks are formatted ext4. If they are, you have
>a bug due to a recent structure change in ext4. If that is the problem,
>you can downgrade your kernel to before they backported the change (not
>sure
Hi Joe,
Problem solved, I'm betting you're genius！！！
The issue is related to ext4, thank you very much!
2012/8/14 Joe Julian
> I'm betting that your bricks are formatted ext4. If they are, you have a
> bug due to a recent structure change in ext4. If that is the problem, you
> can downgrade you
Dear experts,
we started to test gluster (3.3.0) on a small cluster grown over some
time (~200 cores and ~100 TB in heterogeneous hardware). Our data
typically are organised in a tree of directories containing a set of
files with always the same filenames, s.a.
dir1
|- file1 (100 MB)
|- file2
I'm betting that your bricks are formatted ext4. If they are, you have a
bug due to a recent structure change in ext4. If that is the problem,
you can downgrade your kernel to before they backported the change (not
sure which version that is though), or reformat your bricks xfs.
On 08/14/2012
Hi Bryan,
Thank you for your support. Just find out glusterfs 3.2 and 3.3 both have
this issue.
My server is redhat 6.3 kernel is 2.6.32-279.el6.x86_64 is it compatible?
More info listed bellow:
volume info:
Volume Name: yfudis3rep2
Type: Distributed-Replicate
Volume ID: 6a8da204-1348-4cd8-a188
17 matches
Mail list logo
