Hi Linus,
Please pull the following Ceph fix from
git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus
This fixes a bug in the new message decoding that just went in during the
last window.
Thanks!
sage
---
Reviewed-by: Josh Durgin
On 03/11/2013 08:37 AM, Alex Elder wrote:
The first version of this patch had a bug in osd_req_encode_op().
A check intended to see if the source opcode indicated it was
wrong. It did this:
if (CEPH_OSD_OP_WRITE)
when it should have done this:
if (src->op ==
On 03/10/2013 01:35 PM, Alex Elder wrote:
The trail portion of message data was added to support
two distinct sets of data for an osd request--one a
pagelist for providing parameters to object method
calls; and a second a page array for receiving data
back from the result of such a call.
It's al
On 03/11/2013 05:24 PM, Josh Durgin wrote:
> On 03/10/2013 12:06 PM, Alex Elder wrote:
>> This series makes the four distinct data items in a message (the
>> pages array, the pagelist, the bio, and the trail) take a generic
>> form, and then arranges for them all to be handled using a common
>> set
On 03/10/2013 12:06 PM, Alex Elder wrote:
This series makes the four distinct data items in a message (the
pages array, the pagelist, the bio, and the trail) take a generic
form, and then arranges for them all to be handled using a common
set of cursor routines that determine what data needs to b
Dave,
It still a production platform so no I didn't try it. I've also found
that now ceph-mon are constantly leaking... I truly hope your log max
recent = 1 will help.
Cheers.
--
Regards,
Sébastien Han.
On Mon, Mar 11, 2013 at 7:43 PM, Dave Spano wrote:
> Sebastien,
>
> Did the patch that
On 03/09/2013 08:41 AM, Alex Elder wrote:
This series factors out blocks of common code and generally
aims to simplify and make more consistent the way the ceph
messenger processes the data portions of both incoming and
outgoing messages.
They can be found in the "review/wip-msgr-refactor" branc
On 03/11/2013 10:57 AM, Greg Farnum wrote:
> On Monday, March 11, 2013 at 9:48 AM, Jim Schutt wrote:
>> On 03/11/2013 09:48 AM, Greg Farnum wrote:
>>> On Monday, March 11, 2013 at 7:47 AM, Jim Schutt wrote:
For this run, the MDS logging slowed it down enough to cause the
client caps
On 03/11/2013 12:16 PM, Alex Elder wrote:
On 03/11/2013 01:57 PM, Josh Durgin wrote:
On 03/09/2013 07:14 AM, Alex Elder wrote:
Define a new function in_msg_pos_next() to match out_msg_pos_next(),
and use it in place of code at the end of read_partial_message_pages()
and read_partial_message_bio
On 03/11/2013 01:57 PM, Josh Durgin wrote:
> On 03/09/2013 07:14 AM, Alex Elder wrote:
>> Define a new function in_msg_pos_next() to match out_msg_pos_next(),
>> and use it in place of code at the end of read_partial_message_pages()
>> and read_partial_message_bio().
>>
>> Signed-off-by: Alex Elder
Reviewed-by: Josh Durgin
On 03/09/2013 08:36 AM, Alex Elder wrote:
This patch is available in the branch "review/wip-msgr-refactor"
(prior to 6 other patches) in the ceph-client git repository.
That branch is based on branch "review/wip-abstract-2".
-Ale
On 03/09/2013 08:00 AM, Alex Elder wrote:
Over half of these have been reviewed already, but I'm re-posting
them because I've rebased them to be on top of the series I just
posted (that is, these are based on branch "review/wip-cleanup"
or 60b789f libceph: record byte count not page count), and b
On 03/09/2013 07:11 AM, Alex Elder wrote:
This series contains a bunch of small cleanups. All of
them I've created while working on other things, and most
of them were done in order to allow upcoming work to be
easier, or easier to understand. I've moved them all to
the front of my stack of pat
On 03/09/2013 07:14 AM, Alex Elder wrote:
Define a new function in_msg_pos_next() to match out_msg_pos_next(),
and use it in place of code at the end of read_partial_message_pages()
and read_partial_message_bio().
Signed-off-by: Alex Elder
---
net/ceph/messenger.c | 57
+
Hi Bryan,
On 03/11/2013 09:10 AM, Bryan K. Wright wrote:
> s...@inktank.com said:
>> On Thu, 7 Mar 2013, Bryan K. Wright wrote:
>>
>> s...@inktank.com said:
>>> - pg log trimming (probably a conservative subset) to avoid memory bloat
>>
>> Anything that reduces the size of OSD processes would be
That depends on what functionality you want to test...
On 03/11/2013 04:03 AM, waed Albataineh wrote:
Hello there,
For the quick start of Ceph, do i need to continue the RESTful
Gateway quick start ??
even when i will just be testing the basic functions of Ceph!
--
To unsubscri
On Monday, March 11, 2013 at 9:48 AM, Jim Schutt wrote:
> On 03/11/2013 09:48 AM, Greg Farnum wrote:
> > On Monday, March 11, 2013 at 7:47 AM, Jim Schutt wrote:
> > >
> > > For this run, the MDS logging slowed it down enough to cause the
> > > client caps to occasionally go stale. I don't think it
On 03/11/2013 09:48 AM, Greg Farnum wrote:
> On Monday, March 11, 2013 at 7:47 AM, Jim Schutt wrote:
>> On 03/08/2013 07:05 PM, Greg Farnum wrote:
>>> On Friday, March 8, 2013 at 2:45 PM, Jim Schutt wrote:
On 03/07/2013 08:15 AM, Jim Schutt wrote:
> On 03/06/2013 05:18 PM, Greg Farnum wrot
On Monday, March 11, 2013 at 8:10 AM, Bryan K. Wright wrote:
> s...@inktank.com said:
> > On Thu, 7 Mar 2013, Bryan K. Wright wrote:
> >
> > s...@inktank.com said:
> > > - pg log trimming (probably a conservative subset) to avoid memory bloat
> >
> >
> >
> > Anything that reduces the size of
On Monday, March 11, 2013 at 7:47 AM, Jim Schutt wrote:
> On 03/08/2013 07:05 PM, Greg Farnum wrote:
> > On Friday, March 8, 2013 at 2:45 PM, Jim Schutt wrote:
> > > On 03/07/2013 08:15 AM, Jim Schutt wrote:
> > > > On 03/06/2013 05:18 PM, Greg Farnum wrote:
> > > > > On Wednesday, March 6, 2013 at
The first version of this patch had a bug in osd_req_encode_op().
A check intended to see if the source opcode indicated it was
wrong. It did this:
if (CEPH_OSD_OP_WRITE)
when it should have done this:
if (src->op == CEPH_OSD_OP_WRITE)
This versions corrects that problem. The "review/wip-
s...@inktank.com said:
> On Thu, 7 Mar 2013, Bryan K. Wright wrote:
>
> s...@inktank.com said:
> > - pg log trimming (probably a conservative subset) to avoid memory bloat
>
> Anything that reduces the size of OSD processes would be appreciated.
> You can probably do this with just
> log max re
On 03/08/2013 07:05 PM, Greg Farnum wrote:
> On Friday, March 8, 2013 at 2:45 PM, Jim Schutt wrote:
>> On 03/07/2013 08:15 AM, Jim Schutt wrote:
>>> On 03/06/2013 05:18 PM, Greg Farnum wrote:
On Wednesday, March 6, 2013 at 3:14 PM, Jim Schutt wrote:
>>>
>>
>>
>>
>> [snip]
>>
> Do
Thanks. I opened issues #4409, #4410. The first one to improve the
logging on such an error, the second one to make sure we don't die a
horrible death.
On Mon, Mar 11, 2013 at 7:24 AM, Yann ROBIN wrote:
> The socket error was due to nginx opening too much connection, thus reaching
> the limit of
The socket error was due to nginx opening too much connection, thus reaching
the limit of open fd for the gateway.
-Original Message-
From: ceph-devel-ow...@vger.kernel.org
[mailto:ceph-devel-ow...@vger.kernel.org] On Behalf Of Yann ROBIN
Sent: lundi 11 mars 2013 00:40
To: Yehuda Sadeh
C
From: "Yan, Zheng"
Current ceph code tracks directory's completeness in two places.
ceph_readdir() checks i_release_count to decide if it can set the
I_COMPLETE flag in i_ceph_flags. All other places check the I_COMPLETE
flag. This indirection introduces locking complexity.
This patch adds a new
From: "Yan, Zheng"
When pruning a dentry, its ancestor dentry can also be pruned. But
the ancestor dentry does not go through dput(), so it does not get
put on the dentry LRU. Hence associating d_prune with removing the
dentry from the LRU is the wrong.
The fix is remove dentry_lru_prune(). Modi
Last Friday, Florian Haas (CC'ed) commented with regard to the Monitor
changes blog post [1] on Google+ [2]. This is a transcription of the
resulting thread, in which Greg (CC'ed) also participated, and I am now
cross-posting it to the list for the benefit of the larger community on
ceph-devel
28 matches
Mail list logo
