Hello,
We recently bumped again into the same assertion error.
Do you have any indications or update regarding the cause ?
On Tue, Feb 25, 2014 at 11:26:15AM -0800, Noah Watkins wrote:
On Tue, Feb 25, 2014 at 9:51 AM, Josh Durgin josh.dur...@inktank.com wrote:
That's a good idea. This
On Thu, Mar 27, 2014 at 9:30 PM, Alex Elder el...@ieee.org wrote:
On 03/27/2014 01:17 PM, Ilya Dryomov wrote:
Assert length of osd_state, osd_weight and osd_addr arrays. They
should all have exactly max_osd elements after the call to
osdmap_set_max_osd().
Since this function is allowed to
On Thu, Mar 27, 2014 at 9:45 PM, Alex Elder el...@ieee.org wrote:
On 03/27/2014 01:17 PM, Ilya Dryomov wrote:
The size of the memory area feeded to crush_decode() should be limited
not only by osdmap end, but also by the crush map length. Also, drop
You're also letting crush_decode() verify
On Thu, Mar 27, 2014 at 9:49 PM, Alex Elder el...@ieee.org wrote:
On 03/27/2014 01:17 PM, Ilya Dryomov wrote:
The existing error handling scheme requires resetting err to -EINVAL
prior to calling any ceph_decode_* macro. This is ugly and fragile,
and there already are a few places where we
On Thu, Mar 27, 2014 at 9:25 PM, Alex Elder el...@ieee.org wrote:
On 03/27/2014 01:17 PM, Ilya Dryomov wrote:
The existing error handling scheme requires resetting err to -EINVAL
prior to calling any ceph_decode_* macro. This is ugly and fragile,
and there already are a few places where we
Hi Kevin,
Someone mentionned a problem (no more information at the moment ;-) about
running jerasure / gf-complete on a 32 bits machine. Does that ring a bell ?
I'll try it out with the test method you suggested:
'gf_methods w -A -U' to run all of the tests for w=[4,8,16,32,64,128]. Then,
I
On Thu, Mar 27, 2014 at 10:32 PM, Alex Elder el...@ieee.org wrote:
On 03/27/2014 01:18 PM, Ilya Dryomov wrote:
Announce our support for new osdmap enconding.
Looks OK to me. Isn't there a version of this OSD
map encoding? Maybe there'll be a newer one someday?
Reworded to Announce our
On Thu, Mar 27, 2014 at 10:31 PM, Alex Elder el...@ieee.org wrote:
On 03/27/2014 01:18 PM, Ilya Dryomov wrote:
Add two helpers to decode primary_affinity (full map, vectoru32) and
new_primary_affinity (inc map, mapu32, u32) and switch to them.
One comment below, but otherwise looks good.
On Thu, Mar 27, 2014 at 10:49 PM, Alex Elder el...@ieee.org wrote:
On 03/27/2014 01:18 PM, Ilya Dryomov wrote:
Switch ceph_calc_pg_acting() to new helpers: pg_to_raw_osds(),
raw_to_up_osds() and apply_temps().
So that's why you have a temp map in each osdmap.
The result is pretty clean and
On Thu, Mar 27, 2014 at 10:26 PM, Alex Elder el...@ieee.org wrote:
On 03/27/2014 01:18 PM, Ilya Dryomov wrote:
Add primary_affinity infrastructure. primary_affinity values are
stored in an max_osd-sized array, hanging off ceph_osdmap, similar to
a osd_weight array.
Introduce
On Thu, Mar 27, 2014 at 10:17 PM, Alex Elder el...@ieee.org wrote:
On 03/27/2014 01:18 PM, Ilya Dryomov wrote:
Full and incremental osdmaps are structured identically and have
identical headers. Add a helper to decode both old (16-bit version,
v6) and new (8-bit
On Thu, Mar 27, 2014 at 10:59 PM, Alex Elder el...@ieee.org wrote:
On 03/27/2014 01:18 PM, Ilya Dryomov wrote:
Respond to non-default primary_affinity values accordingly. (Primary
affinity allows the admin to shift 'primary responsibility' away from
specific osds, effectively shifting around
Hi Alex, Ilya,
I've added this and the previous patch to a for-linus branch to send to
Linux for 3.14. The net of the two patches is simply removing the assert,
however... the first changes several lines that then get changed back.
Should we squash them?
Thanks!
sage
On Wed, 26 Mar 2014,
On 03/28/2014 07:41 PM, Sage Weil wrote:
Hi Alex, Ilya,
I've added this and the previous patch to a for-linus branch to send to
Linux for 3.14. The net of the two patches is simply removing the assert,
however... the first changes several lines that then get changed back.
Should we
14 matches
Mail list logo
