Re: OSD public / cluster network isolation using VRF:s

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. >

poor performance when recovering

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

Re: OSD public / cluster network isolation using VRF:s

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

Re: OSD public / cluster network isolation using VRF:s

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.,

Re: OSD public / cluster network isolation using VRF:s

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

Re: proposal to run Ceph tests on pull requests

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

Re: OSD public / cluster network isolation using VRF:s

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

Re: OSD public / cluster network isolation using VRF:s

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

Re: OSD public / cluster network isolation using VRF:s

-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

Re: 答复: how to see file object-mappings for cephfuse client

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,

答复: 答复: how to see file object-mappings for cephfuse client

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

Re: testing the /dev/cciss/c0d0 device names

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. >>

Re: [ceph-users] 答复: 答复: how to see file object-mappings for cephfuse client

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

Re: proposal to run Ceph tests on pull requests

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

RDMA/Infiniband

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

Kernel RBD hang on OSD Failure

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

Re: Compiling for FreeBSD, Clang refuses to compile a test

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

Re: Kernel RBD hang on OSD Failure

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

Re: Compiling for FreeBSD, Clang refuses to compile a test

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 +

Re: Compiling for FreeBSD, Clang refuses to compile a test

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

Re: Fwd: Fwd: [newstore (again)] how disable double write WAL

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

Fwd: [ceph-users] poor performance when recovering

-- 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.

Re: 答复: [ceph-users] How long will the logs be kept?

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