Greg,
see below.
On Thu, 2015-12-03 at 13:25 -0800, Gregory Farnum wrote:
> On Thu, Dec 3, 2015 at 12:13 PM, Martin Millnert wrote:
> > Hi,
> >
> > we're deploying Ceph on Linux for multiple purposes.
> > We want to build network isolation in our L3 DC network using VRF:s.
>
Hi, cephers
I'm doing the performance test of ceph when recovering. The scene is simple:
1. run fio on 6 krbd device
2. stop one OSD for 10 seconds
3. start that OSD
However, when the OSD up and start recovering, the performance of fio
drop down from 9k to 1k for about 20 seconds. At the same
On Mon, Dec 7, 2015 at 5:36 AM, Martin Millnert wrote:
> Greg,
>
> see below.
>
> On Thu, 2015-12-03 at 13:25 -0800, Gregory Farnum wrote:
>> On Thu, Dec 3, 2015 at 12:13 PM, Martin Millnert wrote:
>> > Hi,
>> >
>> > we're deploying Ceph on Linux for
On Mon, 2015-12-07 at 06:10 -0800, Sage Weil wrote:
> On Mon, 7 Dec 2015, Martin Millnert wrote:
> > > Note that on a largish cluster the public/client traffic is all
> > > north-south, while the backend traffic is also mostly north-south to the
> > > top-of-rack and then east-west. I.e.,
Wido,
thanks for your feedback.
On Thu, 2015-12-03 at 22:03 +0100, w...@42on.com wrote:
>
> > Op 3 dec. 2015 om 21:14 heeft Martin Millnert het
> > volgende geschreven:
> >
> > Hi,
> >
> > we're deploying Ceph on Linux for multiple purposes.
> > We want to build network
On Mon, Dec 7, 2015 at 3:29 AM, John Spray wrote:
> On Sat, Dec 5, 2015 at 11:49 AM, Loic Dachary wrote:
>> Hi Ceph,
>>
>> TL;DR: a ceph-qa-suite bot running on pull requests is sustainable and is an
>> incentive for contributors to use teuthology-openstack
Sage,
thanks for your feedback, please see below:
On Thu, 2015-12-03 at 13:30 -0800, Sage Weil wrote:
> On Thu, 3 Dec 2015, w...@42on.com wrote:
> > Why all the trouble and complexity? I personally always try to avoid the
> > two networks and run with one. Also in large L3 envs.
> >
> > I like
On Mon, 7 Dec 2015, Martin Millnert wrote:
> > Note that on a largish cluster the public/client traffic is all
> > north-south, while the backend traffic is also mostly north-south to the
> > top-of-rack and then east-west. I.e., within the rack, almost everything
> > is north-south, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
We did some work on prioritizing Ceph traffic and this is what I came up with.
#!/bin/sh
#set -x
if [ $1 == "bond0" ]; then
INTERFACES="enp7s0f0 enp7s0f1"
for i in $INTERFACES; do
# Clear what might be there
On Mon, Dec 7, 2015 at 1:52 PM, Wuxiangwei wrote:
> Thanks Yan, what if we wanna see some more specific or detailed information?
> E.g. with cephfs we may run 'cephfs /mnt/a.txt show_location --offset' to
> find the location of a given offset.
>
When using default layout,
it looks simple if everything stays as its default value. However, we do want
to change the stripe unit size and stripe count to achieve possible higher
performance. If so, it would be too troublesome to manually do the calculation
every time when we want to locate a given offset(and maybe a
Hi,
On 06/12/2015 20:15, Ilya Dryomov wrote:
> On Sat, Dec 5, 2015 at 7:36 PM, Loic Dachary wrote:
>> Hi Ilya,
>>
>> ceph-disk has special handling for device names like /dev/cciss/c0d1 [1] and
>> it was partially broken when support for device mapper was introduced.
>>
On Mon, Dec 7, 2015 at 9:13 AM, Wuxiangwei wrote:
>
> it looks simple if everything stays as its default value. However, we do want
> to change the stripe unit size and stripe count to achieve possible higher
> performance. If so, it would be too troublesome to manually do
On Sat, Dec 5, 2015 at 11:49 AM, Loic Dachary wrote:
> Hi Ceph,
>
> TL;DR: a ceph-qa-suite bot running on pull requests is sustainable and is an
> incentive for contributors to use teuthology-openstack independently
A bot for scheduling a named suite on a named PR, and posting
Hi to all
Any update about infiniband / rdma support in latest ceph version?
I have read that rdma support was planned some time ago, is it now supported ?
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo
Hi,
We have a Ceph cluster in which we have been having issues with RBD
clients hanging when an OSD failure occurs. We are using a NAS gateway
server which maps RBD images to filesystems and serves the filesystems
out via NFS. The gateway server has close to 180 NFS clients and
almost every time
On 5-12-2015 14:02, Xinze Chi (信泽) wrote:
I think "const int k = 12; const int m = 4" would pass the compile?
Are these sizes big enough??
--WjW
2015-12-05 20:56 GMT+08:00 Willem Jan Withagen :
src/test/erasure-code/TestErasureCodeIsa.cc
contains snippets, function
Hi Matt,
(CC'ing in ceph-users too - similar reports there:
http://www.spinics.net/lists/ceph-users/msg23037.html)
We've seen something similar for KVM [lib]RBD clients acting as NFS
gateways within our OpenStack cloud, the NFS services were locking up
and causing client timeouts whenever we
Hi Willem,
If you look at line 411 and 412 you will have variables k and m
defined. They are not changed anywhere(I think), so the sizes must be
big enough.
As Xinze mentioned just add const in front of it:
const int k = 12
const int m = 4
and it should fix the compile error.
buffer::ptr enc[k +
On 7-12-2015 23:19, Michal Jarzabek wrote:
Hi Willem,
If you look at line 411 and 412 you will have variables k and m
defined. They are not changed anywhere(I think), so the sizes must be
big enough.
As Xinze mentioned just add const in front of it:
const int k = 12
const int m = 4
and it
On Fri, Dec 04, 2015 at 03:12:25PM -0500, Ric Wheeler wrote:
> On 12/01/2015 05:02 PM, Sage Weil wrote:
> >Hi David,
> >
> >On Tue, 1 Dec 2015, David Casier wrote:
> >>Hi Sage,
> >>With a standard disk (4 to 6 TB), and a small flash drive, it's easy
> >>to create an ext4 FS with metadata on flash
-- Forwarded message --
From: Libin Wu
Date: 2015-12-08 9:12 GMT+08:00
Subject: Re: [ceph-users] poor performance when recovering
To: Oliver Dzombic
抄送: ceph-users
Yeah, we will upgrade in the near future.
dout() is used for an OSD to log information about what it is doing
locally and might become very chatty. It is saved on the local nodes
disk only.
clog is the cluster log and is used for major events that should be
known by the administrator (see ceph -w). Clog should be used sparingly
23 matches
Mail list logo