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 wrote:
> > That's a good idea. This particular assert in a Mutex
On Thu, Mar 27, 2014 at 9:30 PM, Alex Elder 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 fail, c
On Thu, Mar 27, 2014 at 9:45 PM, Alex Elder 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 it has t
On Thu, Mar 27, 2014 at 9:49 PM, Alex Elder 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 would retu
On 03/28/2014 09:56 AM, Ilya Dryomov wrote:
> On Thu, Mar 27, 2014 at 9:25 PM, Alex Elder 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
On Thu, Mar 27, 2014 at 9:25 PM, Alex Elder 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 would retu
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 -A -U' to run all of the tests for w=[4,8,16,32,64,128]. Then,
I in
On Thu, Mar 27, 2014 at 10:32 PM, Alex Elder 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 support
On Thu, Mar 27, 2014 at 10:31 PM, Alex Elder wrote:
> On 03/27/2014 01:18 PM, Ilya Dryomov wrote:
>> Add two helpers to decode primary_affinity (full map, vector) and
>> new_primary_affinity (inc map, map) and switch to them.
>
> One comment below, but otherwise looks good.
>
> Reviewed-by: Alex E
On Thu, Mar 27, 2014 at 10:49 PM, Alex Elder 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 you elim
On Thu, Mar 27, 2014 at 10:26 PM, Alex Elder 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 {get,set}_primary_a
On Thu, Mar 27, 2014 at 10:17 PM, Alex Elder 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 struct_v+struct_compat+struct_len,
On Thu, Mar 27, 2014 at 10:59 PM, Alex Elder 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 the read
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, A
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 w
On 03/29/2014 02:37 AM, Milosz Tanski wrote:
> I try to run the testing branch of the kernel client on one set of my
> clients. And currently in testing
> (a139081b7a9d10a9610f1b5a551fa2d95c04c80d to be exact) I'm seeing a
> bug where I only see part of the directory structure. I looked at the
> pa
16 matches
Mail list logo
