[PATCH] rbd: don't put snap_context twice in rbd_queue_workfn()

Commit 4e752f0ab0e8 ("rbd: access snapshot context and mapping size safely") moved ceph_get_snap_context() out of rbd_img_request_create() and into rbd_queue_workfn(), adding a ceph_put_snap_context() to the error path in rbd_queue_workfn(). However, rbd_img_request_create() consumes a ref on

nightlies on firefly removed

As we are nearing EOL for firefly release all nightlies run on firefly branch were disabled. Let me know if this presents any problems. Thx YuriW -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH] rbd: don't put snap_context twice in rbd_queue_workfn()

On 12/01/2015 12:04 PM, Ilya Dryomov wrote: Commit 4e752f0ab0e8 ("rbd: access snapshot context and mapping size safely") moved ceph_get_snap_context() out of rbd_img_request_create() and into rbd_queue_workfn(), adding a ceph_put_snap_context() to the error path in rbd_queue_workfn(). However,

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

FYI -- Forwarded message -- From: David Casier Date: 2015-12-01 21:32 GMT+01:00 Subject: Re: Fwd: [newstore (again)] how disable double write WAL To: Sage Weil Cc: Sébastien VALSEMEY , Vish Maram-SSI

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

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 > > Example with sdg1 on flash and sdb on hdd : > > size_of() { > blockdev --getsize $1 > } > > mkdmsetup() { >

Re: How to open clog debug

Hi Joao, 2015-12-01 22:34 GMT+08:00 Joao Eduardo Luis : > On 12/01/2015 09:13 AM, Zhiqiang Wang wrote: >> Looks like in the current code, the clog generated by OSD and MDS are >> not sent to MON. When the client subscribes to the log monitor, it >> won't get the OSD and MDS clogs.

Re: Cache Tiering Investigation and Potential Patch

On 12/01/2015 10:30 AM, Nick Fisk wrote: Hi Sage/Mark, I have completed some initial testing of the tiering fix PR you submitted compared to my method I demonstrated at the perf meeting last week. From a high level both have very similar performance when compared to the current broken

Re: Compiling for FreeBSD

On Tue, Dec 1, 2015 at 9:24 AM, Willem Jan Withagen wrote: > On 1-12-2015 15:35, Sage Weil wrote: >> >> On Tue, 1 Dec 2015, Willem Jan Withagen wrote: >>> >>> On 1-12-2015 14:30, Sage Weil wrote: On Tue, 1 Dec 2015, Willem Jan Withagen wrote: > > On 30-11-2015

Re: Compiling for FreeBSD

On 1-12-2015 15:35, Sage Weil wrote: On Tue, 1 Dec 2015, Willem Jan Withagen wrote: On 1-12-2015 14:30, Sage Weil wrote: On Tue, 1 Dec 2015, Willem Jan Withagen wrote: On 30-11-2015 14:21, Sage Weil wrote: The problem with all of the porting code in general is that it is doomed to break

Re: Compiling for FreeBSD

On 1-12-2015 18:22, Alan Somers wrote: I did some work porting Ceph to FreeBSD, but got distracted and stopped about two years ago. You may find this port useful, though it will probably need to be updated: https://people.freebsd.org/~asomers/ports/net/ceph/ I'll chcek that one as well...

Re: Compiling for FreeBSD

On Tue, Dec 1, 2015 at 11:08 AM, Willem Jan Withagen wrote: > On 1-12-2015 18:22, Alan Somers wrote: >> >> I did some work porting Ceph to FreeBSD, but got distracted and >> stopped about two years ago. You may find this port useful, though it >> will probably need to be

Re: Compiling for FreeBSD

On 1-12-2015 19:21, Alan Somers wrote: On Tue, Dec 1, 2015 at 11:08 AM, Willem Jan Withagen wrote: On 1-12-2015 18:22, Alan Somers wrote: I did some work porting Ceph to FreeBSD, but got distracted and stopped about two years ago. You may find this port useful, though it

Re: Compiling for FreeBSD

On 1-12-2015 19:36, Sage Weil wrote: On Tue, 1 Dec 2015, Alan Somers wrote: On Tue, Dec 1, 2015 at 11:08 AM, Willem Jan Withagen wrote: On 1-12-2015 18:22, Alan Somers wrote: I did some work porting Ceph to FreeBSD, but got distracted and stopped about two years ago. You

Re: Compiling for FreeBSD

On Tue, 1 Dec 2015, Alan Somers wrote: > On Tue, Dec 1, 2015 at 11:08 AM, Willem Jan Withagen wrote: > > On 1-12-2015 18:22, Alan Somers wrote: > >> > >> I did some work porting Ceph to FreeBSD, but got distracted and > >> stopped about two years ago. You may find this port

Re: Compiling for FreeBSD

On 1-12-2015 17:24, Willem Jan Withagen wrote: I think in the short run it will not be the code that is going to be a major porting pain. But getting the run-time environment ironed out is just plain (hard) work. Things where /bin/sh expects certain bash-isms. Where paths have not been setup to

issues running teuthology-openstack on private cloud

Hi, I’m trying to get set up to use teuthology to run tests on an in-house openstack cloud. Is this list the appropriate venue? I had to make 2 changes to get teuthology-openstack to run on my dev machine; first there is a hardcoded set of providers in OpenStack.set_provider to match the

Re: How to open clog debug

Looks like in the current code, the clog generated by OSD and MDS are not sent to MON. When the client subscribes to the log monitor, it won't get the OSD and MDS clogs. It only gets those generated by MON. 2015-11-30 21:24 GMT+08:00 Sage Weil : > On Mon, 30 Nov 2015,

Re: Compiling for FreeBSD

On 30-11-2015 17:20, Gregory Farnum wrote: Installed the results: gmake install And looked at what it delivered: zfs diff And I have to be honest that I'm not really enjoying all the ceph-test stuff in my /usr/local/bin Would prefer it to go into something like:

Re: CodingStyle on existing code

On 01-12-15 16:00, Gregory Farnum wrote: > On Tue, Dec 1, 2015 at 5:47 AM, Loic Dachary wrote: >> >> >> On 01/12/2015 14:10, Wido den Hollander wrote: >>> Hi, >>> >>> While working on mon/PGMonitor.cc I see that there is a lot of >>> inconsistency on the code. >>> >>> A lot of

Re: CodingStyle on existing code

On Tue, 1 Dec 2015, Wido den Hollander wrote: > > On 01-12-15 16:00, Gregory Farnum wrote: > > On Tue, Dec 1, 2015 at 5:47 AM, Loic Dachary wrote: > >> > >> > >> On 01/12/2015 14:10, Wido den Hollander wrote: > >>> Hi, > >>> > >>> While working on mon/PGMonitor.cc I see that

Re: Compiling for FreeBSD

On 1-12-2015 13:22, Mykola Golub wrote: On Tue, Dec 01, 2015 at 10:42:57AM +0100, Willem Jan Withagen wrote: On 30-11-2015 17:20, Gregory Farnum wrote: Installed the results: gmake install And looked at what it delivered: zfs diff And I have to be honest that I'm not really

Troublesome documentation link on http://ceph.com

So I go to http://ceph.com and click on the "Documentation" link. In the HTML source code the linked URL is http://ceph.com/docs but the HTTP server rewrites this to: http://docs.ceph.com/docs/v0.80.5/ Could someone arrange for this to be changed s/v0.80.5/master/ ? ( Searching for Ceph

Re: Compiling for FreeBSD

On 30-11-2015 14:21, Sage Weil wrote: The problem with all of the porting code in general is that it is doomed to break later on if we don't have (at least) ongoing build tests. In order for a FreeBSD or OSX port to continue working we need VMs that run either gitbuilder or a jenkins job or

Re: Compiling for FreeBSD

On Tue, Dec 01, 2015 at 10:42:57AM +0100, Willem Jan Withagen wrote: > On 30-11-2015 17:20, Gregory Farnum wrote: > >>Installed the results: > >>gmake install > >> > >>And looked at what it delivered: > >> zfs diff > >> > >>And I have to be honest that I'm not really enjoying all the

CodingStyle on existing code

Hi, While working on mon/PGMonitor.cc I see that there is a lot of inconsistency on the code. A lot of whitespaces, indentation which is not correct, well, a lot of things. Is this something we want to fix? With some scripts we can probably do this easily, but it might cause merge hell with

Re: Compiling for FreeBSD

On Tue, 1 Dec 2015, Willem Jan Withagen wrote: > On 1-12-2015 14:30, Sage Weil wrote: > > On Tue, 1 Dec 2015, Willem Jan Withagen wrote: > > > On 30-11-2015 14:21, Sage Weil wrote: > > > > The problem with all of the porting code in general is that it is doomed > > > > to break later on if we

Re: How to open clog debug

On 12/01/2015 09:13 AM, Zhiqiang Wang wrote: > Looks like in the current code, the clog generated by OSD and MDS are > not sent to MON. When the client subscribes to the log monitor, it > won't get the OSD and MDS clogs. It only gets those generated by MON. Most likely, you need to set

Re: CodingStyle on existing code

On Tue, Dec 1, 2015 at 5:47 AM, Loic Dachary wrote: > > > On 01/12/2015 14:10, Wido den Hollander wrote: >> Hi, >> >> While working on mon/PGMonitor.cc I see that there is a lot of >> inconsistency on the code. >> >> A lot of whitespaces, indentation which is not correct, well,

Re: Compiling for FreeBSD

On Tue, 1 Dec 2015, Willem Jan Withagen wrote: > On 30-11-2015 14:21, Sage Weil wrote: > > The problem with all of the porting code in general is that it is doomed > > to break later on if we don't have (at least) ongoing build tests. In > > order for a FreeBSD or OSX port to continue working we

Re: CodingStyle on existing code

On 01/12/2015 14:10, Wido den Hollander wrote: > Hi, > > While working on mon/PGMonitor.cc I see that there is a lot of > inconsistency on the code. > > A lot of whitespaces, indentation which is not correct, well, a lot of > things. > > Is this something we want to fix? With some scripts we

Suggestions on tracker 13578

Hello, This mail is to discuss the feature request at http://tracker.ceph.com/issues/13578. If done, such a tool should help point out several mis-configurations that may cause problems in a cluster later. Some of the suggestions are: a) A check to understand if the MONs and OSD nodes are

Re: Compiling for FreeBSD

On 1-12-2015 14:30, Sage Weil wrote: On Tue, 1 Dec 2015, Willem Jan Withagen wrote: On 30-11-2015 14:21, Sage Weil wrote: The problem with all of the porting code in general is that it is doomed to break later on if we don't have (at least) ongoing build tests. In order for a FreeBSD or OSX