thought this might be of interest to you all out there:
http://opensource.com/life/12/10/NASA-achieves-data-goals-Mars-rover-open-source-software
___
Gluster-users mailing list
Gluster-users@gluster.org
http://supercolony.gluster.org/mailman/listinfo/glu
Corey,
Make sure to test with direct I/O, otherwise the caching can give you
unrealistic expectations of your actual throughput. Typically, using the ipoib
driver is not recommended with Infiniband since you will introduce unnecessary
overhead via TCP.
Knowing how you have Gluster configured
> gluster volume create vol1 replica 2 transport tcp server1:/brick1
> server2:/brick2 server3:/brick3 server4:/brick4
>
> server1:/brick1 and server2:/brick2 are the first replica pair
>
> server3:/brick3 and server4:/brick4 are the second replica pair
>
> server1.. file1 goes into brick1/brick2
On ma. 22. okt. 2012 kl. 19.11 +0200, Brian Candler wrote:
On Thu, Oct 18, 2012 at 06:48:42PM +0200, Runar Ingebrigtsen wrote:
The connection break behavior is to be expected - the TCP connection
doesn't handle the switch of host. I didn't expect the NFS client to go
stale.
I can't
On 10/22/2012 10:37 AM, Joe Julian wrote:
> The client will read from the first-to-respond.
That's true, but it's going to change in a couple of ways.
* Commit 0baa12e8 (March 23) will cause replication to read from a brick on the
same machine if there is one.
* Commit 97819bf2 (June 24) provide
On Thu, Oct 18, 2012 at 06:48:42PM +0200, Runar Ingebrigtsen wrote:
>The connection break behavior is to be expected - the TCP connection
>doesn't handle the switch of host. I didn't expect the NFS client to go
>stale.
I can't answer this directly but I did notice something in the 3.3.
Thanks for reporting. That particular item is no longer relevant and will
be deprecated.
Thanks,
JM
On Sat, Oct 20, 2012 at 2:03 AM, kunal khaneja wrote:
> Dear Team,
>
> Please note that many download links of gluster.org redirect
> to redhat.com. Please refer below links and
>
hi,all:
when I`m deleting a file (about 1GB) or folders of the volume, I tried to
add one brick to the volume.
Then the deleting was halted with the error msg: "rm: cann't delete XXX,
transport endpoint is not connected".
I`m not sure, is it a bug, or a yet-to-be-added featu
Dear Team,
Please note that many download links of gluster.org redirect to
redhat.com. Please refer below links and
correct download link.
http://gluster.org/community/documentation/index.php/Gluster_3.2:_Downloading_and_Installing_the_Gluster_Virtual_Storage_Appliance_
Hi,
we've successfully configured GlusterFS mirroring across two identical
nodes [1].
We're running the file share under a Virtual IP address using UCarp.
We have different clients connected using NFS, CIFS and GlusterFS.
When we simulate a node failure, by unplugging it, it takes about 5
se
I have four servers, absolutely identical, connected to the same switches. One
interface is on a 100Mb switch, the other is on a 1Gb switch. I access the
nodes via the 100Mb port, gluster is configured on the 1Gb port. The nodes are
all loaded with Scientific Linux 6.3, Virtualization Host, with
hi Amar,
I met across a problem when I replace a brick in a stripe-replicate volume.
I used both methods you mentioned in your post.
#gluster volume replace-brick brick1 brick2 start [1]
# gluster volume replace-brick brick1 brick2 commit force
(self-heal daemon heals the data)
the message shows
Israel - thank you for taking the time to write out more thoughtful responses.
See below for my responses inline.
- Original Message -
> On 10/21/2012 02:18 PM, Israel Shirk wrote:
> > Haris, try the NFS mount. Gluster typically triggers healing
> > through
> > the client, so if you ski
I'm sorry you took that email as an "I'm always right" sort of thing.
You were telling a user that things were a certain way and for the
majority of users that I encounter on a daily basis, it's just not true.
I wanted to set the record straight so that user can make a properly
informed decisio
On Mon, Oct 22, 2012 at 08:55:18AM -0600, Israel Shirk wrote:
> I'm simply saying that I keep hearing that Gluster is supposed to work great
> on
> distributed applications (as in distributed to more than one place), but the
> reality of the situation is that it's really buggy and nobody is willi
On 10/21/2012 02:18 PM, Israel Shirk wrote:
> Haris, try the NFS mount. Gluster typically triggers healing through
> the client, so if you skip the client, nothing heals.
Not true anymore. With 3.3 there's a self-heal daemon that will handle
the heals. You do risk reading stale data if you don't r
- Original Message -
> > False. The client will read from the first-to-respond. Yes, if
> > Singapore is responding faster than Virginia you might want to
> > figure
> > out why Virginia is so overloaded that it's taking more than 200ms
> > to
> > respond, but really that shouldn't be the
On 10/22/2012 07:37 AM, Joe Julian wrote:
The native Gluster client tends to be really @#$@#$@# stupid. It'll
send reads to Singapore while you're in Virginia (and there are
bricks 0.2ms away),
False. The client will read from the first-to-respond. Yes, if
Singapore is responding faster than V
On 10/21/2012 02:18 PM, Israel Shirk wrote:
Haris, try the NFS mount. Gluster typically triggers healing through
the client, so if you skip the client, nothing heals.
Not true anymore. With 3.3 there's a self-heal daemon that will handle
the heals. You do risk reading stale data if you don't re
On 10/22/2012 09:42 AM, Dan Bretherton wrote:
Incidentally, when I decided to downgrade 3.3.0 I discovered that those
RPMs aren't available for download from http://download.glusterfs.org or
http://repos.fedorapeople.org/repos/kkeithle/glusterfs (epel-glusterfs)
any more.
The old 3.3.0 RPMs fr
On 10/22/2012 09:42 AM, Dan Bretherton wrote:
> Dear All-
> I upgraded from 3.3.0 to 3.3.1 from the epel-glusterfs repository a few
> days ago, but I discovered that NFS in the new version does not work
> with virtual IP addresses managed by CARP. NFS crashed as soon as an
> NFS client made an
Dan - if you need to downgrade, see Kaleb's repo here:
http://repos.fedorapeople.org/repos/kkeithle/glusterfs/old/3.3.0-11/
-JM
On Mon, Oct 22, 2012 at 9:42 AM, Dan Bretherton <
d.a.brether...@reading.ac.uk> wrote:
> Dear All-
> I upgraded from 3.3.0 to 3.3.1 from the epel-glusterfs repository
On Mon, Oct 22, 2012 at 09:49:21AM -0400, John Mark Walker wrote:
> Dan - please file a bug re: the NFS issue.
Glad to hear this will be treated as a bug. If NFS is to be supported at
all, being able to use a virtual-IP setup (whether mediated by CARP or
otherwise) is essential. And considering t
Dan - please file a bug re: the NFS issue.
Also, older builds were sacrificed when the older download server was lost.
I'll contact our main packager about doing 3.0 builds.
The builds on bits.gluster.org are strictly for testing purposes only -
they don't upgrade cleanly to other builds. I would
Dear All-
I upgraded from 3.3.0 to 3.3.1 from the epel-glusterfs repository a few
days ago, but I discovered that NFS in the new version does not work
with virtual IP addresses managed by CARP. NFS crashed as soon as an
NFS client made an attempt to mount a volume using a virtual IP address,
On 22 October 2012 14:57, Tao Lin wrote:
> Hi, dear glfs experts:
> I've been using glusterfs (version 3.2.6) for months,so far it works very
> well.Now I'm facing a problem of adding two new bricks to an existed
> replicated (rep=2) volume,which is consisted of only two bricks and is
> mounted
* Patrick Irvine [2012 10 16, 22:03]:
> Can I do a simple rolling upgrade from 3.3.0 to 3.3.1? Or are
> there some gotchas?
I haven't seen any answer to this enquiry, though I think it is very
simple and important to know the answer. Can 3.3.0/3.3.1 bricks
coexist? What about clients, can 3.3.1
Dear All-
A replicated pair of servers in my GlusterFS 3.3.0 cluster have been
experiencing extremely high load for the past few days after a
replicated brick pair became 100% full. The GlusterFS related load on
one of the servers was fluctuating at around 60, and this high load
would swap to
Hi, dear glfs experts:
I've been using glusterfs (version 3.2.6) for months,so far it works very
well.Now I'm facing a problem of adding two new bricks to an existed
replicated (rep=2) volume,which is consisted of only two bricks and is
mounted by multiple clients.Can I just use the following co
I have the same experiance. All comunication goes through ethernet. I
think the documentation should be changed to "NOT SUPPORTED AT ALL!",
because with my broken english I figured that there was no commercial
support for rdma, but the code is there.
On 10/19/12 9:00 PM, Bartek Krawczyk wrote:
Thank you for your answer...
Does using the NFS client insure replication to all bricks? My problem
is that I see Gluster has "unfinished" replication tasks that lie
around. Seems like the Gluster needs an external trigger to like "ls -l"
on the file in question to re-trigger and complete the r
31 matches
Mail list logo
