[no subject]

Hi Joao, We have a problem when trying to add new monitors to the cluster on an unhealthy cluster, which I would like ask for your suggestion. After adding the new monitor, it started syncing the store and went into an infinite loop: 2015-11-12 21:02:23.499510 7f1e8030e700 10

Re: Notes from a discussion a design to allow EC overwrites

Lazily persisting the intermediate entries would certainly also work, but there's an argument that it needlessly adds to the write transaction. Actually, we probably want to avoid having small writes be full stripe writes -- with a 8+3 code the difference between modifying a single stripelet and

RE: Notes from a discussion a design to allow EC overwrites

This scheme fundamentally relies on the temporary objects "gracefully" transitioning into being portions of full-up long-term durable objects. This means that if the allocation size for a temporary object significantly mismatches the size of the mutation (partial stripe write) you're creating a

Re: recommendations for good newbie bug to look at?

>Looks like we only have two tagged right now :( but periodically >things in the tracker get tagged with "new-dev". > >http://tracker.ceph.com/projects/ceph/search?utf8=✓=1=new-dev > >...and looking at that, the osdmap_subscribe ones I think are mostly >dealt with in

Re: Notes from a discussion a design to allow EC overwrites

Hi: sorry for half send. I'm working on this recently. I think we should distinguish the scene of sequence write and small write. The first, overwrite is enough. The second small write's typical optimal is a log based write, which do not need ec's reconstruct and avoid parity chunk's extra

recommendations for good newbie bug to look at?

Hello, I’m looking to get my feet wet with the ceph project, and was wondering if anyone had some advice for a good bug to look at? Thanks, -Emile N�r��yb�X��ǧv�^�)޺{.n�+���z�]z���{ay�ʇڙ�,j��f���h���z��w��� ���j:+v���w�j�mzZ+�ݢj"��!�i

Re: recommendations for good newbie bug to look at?

Looks like we only have two tagged right now :( but periodically things in the tracker get tagged with "new-dev". http://tracker.ceph.com/projects/ceph/search?utf8=✓=1=new-dev ...and looking at that, the osdmap_subscribe ones I think are mostly dealt with in

Re: Firefly EOL date - still Jan 2016?

> Does anyone on the stable release team have an interest in doing > releases beyond that date, or should we announce that as a firm date? For now my vote is to stick to the schedule and declare EOL on January 31, but I'm willing to negotiate :-) Nathan -- To unsubscribe from this list: send the

Firefly EOL date - still Jan 2016?

Hi folks, This is mainly directed at the stable release team members (http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO), since they are the ones doing the work of backporting :) On http://docs.ceph.com/docs/master/releases/, it says the estimated EOL for Firefly is Jan 2016, which is

Re: Firefly EOL date - still Jan 2016?

Hi Ken, On 13/11/2015 22:15, Ken Dreyer wrote: > Hi folks, > > This is mainly directed at the stable release team members > (http://tracker.ceph.com/projects/ceph-releases/wiki/HOWTO), since > they are the ones doing the work of backporting :) > > On http://docs.ceph.com/docs/master/releases/,

Re: Newly added monitor infinitely sync store

On Fri, 13 Nov 2015, Guang Yang wrote: > I was wrong the previous analysis, it was not the iterator got reset, > the problem I can see now, is that during the syncing, a new round of > election kicked off and thus it needs to probe the newly added > monitor, however, since it hasn't been synced

Re: Newly added monitor infinitely sync store

On Fri, 13 Nov 2015, Guang Yang wrote: > Thanks Sage! > > On Fri, Nov 13, 2015 at 4:15 PM, Sage Weil wrote: > > On Fri, 13 Nov 2015, Guang Yang wrote: > >> I was wrong the previous analysis, it was not the iterator got reset, > >> the problem I can see now, is that during the

Re: Newly added monitor infinitely sync store

Thanks Sage! I will definitely try those patches. For this one, I finally managed to bring the new monitor in by increasing the mon_sync_timeout from its default 60 to 6 to make sure the syncing does not restart and result in an infinite loop.. On Fri, Nov 13, 2015 at 5:04 PM, Sage Weil

Newly added monitor infinitely sync store

I was wrong the previous analysis, it was not the iterator got reset, the problem I can see now, is that during the syncing, a new round of election kicked off and thus it needs to probe the newly added monitor, however, since it hasn't been synced yet, it will restart the syncing from there. Hi

Re: Newly added monitor infinitely sync store

Thanks Sage! On Fri, Nov 13, 2015 at 4:15 PM, Sage Weil wrote: > On Fri, 13 Nov 2015, Guang Yang wrote: >> I was wrong the previous analysis, it was not the iterator got reset, >> the problem I can see now, is that during the syncing, a new round of >> election kicked off and

Re: data-at-rest compression

On Fri, 13 Nov 2015, Alyona Kiselyova wrote: > Hi, > I was working on pluggable compression interface in this work > (https://github.com/ceph/ceph/pull/6361). In Igor's pull request was > suggested to reuse common plugin infrastructure from unmerged > wip-plugin branch. Now I'm working on

Re: Notes from a discussion a design to allow EC overwrites

On Thu, 12 Nov 2015, Samuel Just wrote: > I was present for a discussion about allowing EC overwrites and thought it > would be good to summarize it for the list: > > Commit Protocol: > 1) client sends write to primary > 2) primary reads in partial stripes needed for partial stripe > overwrites