Hi
We found something else.
After osd.72 flapp, one PG '3.54d' was recovering long time.
--
ceph health details
HEALTH_WARN 1 pgs recovering; recovery 1/39821745 degraded (0.000%)
pg 3.54d is active+recovering, acting [72,108,23]
recovery 1/39821745 degraded (0.000%)
--
Last flap down/up osd.72 w
We did not upgrade from bobtail to cuttlefish and are still seeing this
issue. I posted this on the ceph-users mailinglist and I missed this
thread (sorry!) so I didn't know.
Either way, I also have an osd crashing after upgrading to 0.61.6. As
said on the other list, I'm more than happy to sh
On Thu, Jul 25, 2013 at 2:55 PM, majianpeng wrote:
>>On Thu, 25 Jul 2013, majianpeng wrote:
>>> Hi all,
>>> I met a problem and ask somebody could help me.
>>> In func striped_read()
>>> > if (ret > 0) {
>>> >int didpages = (page_align + ret) >> PAGE_CACHE_SHIFT;
>>>
>>> >
s/for take the time/for taking the time/
:-)
On 24/07/2013 17:00, Loic Dachary wrote:
> Hi,
>
> Thanks for take the time to discuss LFS today @ OSCON :-) Would you be so
> kind as to send links to the current discussion about the LFS driver API ?
>
> Cheers
>
--
Loïc Dachary, Artisan Logic
I just wanted to follow up to say that after applying these patches
and running it for a few weeks we're I haven't seen another lock up
under load.
- Milosz
On Mon, Jul 8, 2013 at 5:16 PM, Milosz Tanski wrote:
> In this case (unlike last week) the restart did unlock my clients.
>
> - M
>
> On Mo
On Thu, 25 Jul 2013, pe...@2force.nl wrote:
> We did not upgrade from bobtail to cuttlefish and are still seeing this issue.
> I posted this on the ceph-users mailinglist and I missed this thread (sorry!)
> so I didn't know.
That's interesting; a bobtail upgraded cluster was the only way I was abl
On Thu, 25 Jul 2013, Yan, Zheng wrote:
> On Thu, Jul 25, 2013 at 2:55 PM, majianpeng wrote:
> >>On Thu, 25 Jul 2013, majianpeng wrote:
> >>> Hi all,
> >>> I met a problem and ask somebody could help me.
> >>> In func striped_read()
> >>> > if (ret > 0) {
> >>> >int didpages =
On 2013-07-25 17:46, Sage Weil wrote:
On Thu, 25 Jul 2013, pe...@2force.nl wrote:
We did not upgrade from bobtail to cuttlefish and are still seeing
this issue.
I posted this on the ceph-users mailinglist and I missed this thread
(sorry!)
so I didn't know.
That's interesting; a bobtail upgra
On Thu, Jul 25, 2013 at 12:47 AM, Mostowiec Dominik
wrote:
> Hi
> We found something else.
> After osd.72 flapp, one PG '3.54d' was recovering long time.
>
> --
> ceph health details
> HEALTH_WARN 1 pgs recovering; recovery 1/39821745 degraded (0.000%)
> pg 3.54d is active+recovering, acting [72,1
--- Begin Message ---
Hi,
Please find the latest report on new defect(s) introduced to ceph found with
Coverity Scan
Defect(s) Reported-by: Coverity Scan
** CID 1057291: Resource leak (RESOURCE_LEAK)
/rgw/rgw_rados.cc: 2643
__
I'm already signed up. Looking forward to it!
- Travis
On Thu, Jul 25, 2013 at 12:19 AM, Sage Weil wrote:
> I'm going to be in NYC next week at our first Ceph Day of the summer. If
> you're in town and want to hear more about what we're doing, you should
> join us!
>
> http://www.inktank.com/
This release fixes another regression preventing monitors to start after
undergoing certain upgrade sequences, as well as some corner cases with
Paxos and unusual device names in ceph-disk/cephde-loy.
Notable changes:
* mon: fix regression in latest full osdmap retrieval
* mon: fix a long-sta
I've added a blueprint for avoiding double-writes when using btrfs:
http://wiki.ceph.com/01Planning/02Blueprints/Emperor/osd:_clone_from_journal_on_btrfs
This should improve throughput significantly when the journal is a file in
btrfs.
---
Also, there's one for improving the localized
On Thu, Jul 25, 2013 at 4:01 PM, Sage Weil wrote:
> I've added a blueprint for avoiding double-writes when using btrfs:
>
>
> http://wiki.ceph.com/01Planning/02Blueprints/Emperor/osd:_clone_from_journal_on_btrfs
>
> This should improve throughput significantly when the journal is a file i
On Thu, 25 Jul 2013, Gregory Farnum wrote:
> On Thu, Jul 25, 2013 at 4:01 PM, Sage Weil wrote:
> > I've added a blueprint for avoiding double-writes when using btrfs:
> >
> >
> > http://wiki.ceph.com/01Planning/02Blueprints/Emperor/osd:_clone_from_journal_on_btrfs
> >
> > This should impr
On Thu, Jul 25, 2013 at 4:28 PM, Sage Weil wrote:
> On Thu, 25 Jul 2013, Gregory Farnum wrote:
>> On Thu, Jul 25, 2013 at 4:01 PM, Sage Weil wrote:
>> > I've added a blueprint for avoiding double-writes when using btrfs:
>> >
>> >
>> > http://wiki.ceph.com/01Planning/02Blueprints/Emperor
On Thu, 25 Jul 2013, Gregory Farnum wrote:
> On Thu, Jul 25, 2013 at 4:28 PM, Sage Weil wrote:
> > On Thu, 25 Jul 2013, Gregory Farnum wrote:
> >> On Thu, Jul 25, 2013 at 4:01 PM, Sage Weil wrote:
> >> > I've added a blueprint for avoiding double-writes when using btrfs:
> >> >
> >> >
>
http://wiki.ceph.com/01Planning/02Blueprints/Emperor/osd:_ceph_on_zfs
We've done some preliminary testing and xattr debugging that allows
ceph-osd to run on zfsforlinux using the normal writeahead journaling mode
(the same mode used for xfs and ext4). However, we aren't doing anything
special
>On Thu, 25 Jul 2013, Yan, Zheng wrote:
>> On Thu, Jul 25, 2013 at 2:55 PM, majianpeng wrote:
>> >>On Thu, 25 Jul 2013, majianpeng wrote:
>> >>> Hi all,
>> >>> I met a problem and ask somebody could help me.
>> >>> In func striped_read()
>> >>> > if (ret > 0) {
>> >>> >int did
On Fri, Jul 26, 2013 at 8:48 AM, majianpeng wrote:
>>On Thu, 25 Jul 2013, Yan, Zheng wrote:
>>> On Thu, Jul 25, 2013 at 2:55 PM, majianpeng wrote:
>>> >>On Thu, 25 Jul 2013, majianpeng wrote:
>>> >>> Hi all,
>>> >>> I met a problem and ask somebody could help me.
>>> >>> In func striped_read
>On Fri, Jul 26, 2013 at 8:48 AM, majianpeng wrote:
>>>On Thu, 25 Jul 2013, Yan, Zheng wrote:
On Thu, Jul 25, 2013 at 2:55 PM, majianpeng wrote:
>>On Thu, 25 Jul 2013, majianpeng wrote:
>>> Hi all,
>>> I met a problem and ask somebody could help me.
>>> In func strip
On Fri, Jul 26, 2013 at 9:22 AM, majianpeng wrote:
>>On Fri, Jul 26, 2013 at 8:48 AM, majianpeng wrote:
On Thu, 25 Jul 2013, Yan, Zheng wrote:
> On Thu, Jul 25, 2013 at 2:55 PM, majianpeng wrote:
> >>On Thu, 25 Jul 2013, majianpeng wrote:
> >>> Hi all,
> >>> I met a prob
>On Fri, Jul 26, 2013 at 9:22 AM, majianpeng wrote:
>>>On Fri, Jul 26, 2013 at 8:48 AM, majianpeng wrote:
>On Thu, 25 Jul 2013, Yan, Zheng wrote:
>> On Thu, Jul 25, 2013 at 2:55 PM, majianpeng wrote:
>> >>On Thu, 25 Jul 2013, majianpeng wrote:
>> >>> Hi all,
>> >>> I met
On Fri, Jul 26, 2013 at 9:38 AM, majianpeng wrote:
>>On Fri, Jul 26, 2013 at 9:22 AM, majianpeng wrote:
On Fri, Jul 26, 2013 at 8:48 AM, majianpeng wrote:
>>On Thu, 25 Jul 2013, Yan, Zheng wrote:
>>> On Thu, Jul 25, 2013 at 2:55 PM, majianpeng
>>> wrote:
>>> >>On Thu, 25 Ju
>On Fri, Jul 26, 2013 at 9:38 AM, majianpeng wrote:
>>>On Fri, Jul 26, 2013 at 9:22 AM, majianpeng wrote:
>On Fri, Jul 26, 2013 at 8:48 AM, majianpeng wrote:
>>>On Thu, 25 Jul 2013, Yan, Zheng wrote:
On Thu, Jul 25, 2013 at 2:55 PM, majianpeng
wrote:
>>On Thu
The error ENOENT from osd has special meaning.It means the data of
read-area are all-zero.In order to reduce the flow between client and
osd, it used this method.
Signed-off-by: Jianpeng Ma
---
fs/ceph/file.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fs/ceph/file.c b/fs/ceph/file.
If we met checkeof,it only for eof rather than hithole.So update the
comments.
Signed-off-by: Jianpeng Ma
---
fs/ceph/file.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ceph/file.c b/fs/ceph/file.c
index 2ddf061..d1b5f61 100644
--- a/fs/ceph/file.c
+++ b/fs/ceph/fi
27 matches
Mail list logo